Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Feb 28, 2020 12:38 am

Unanswered topics | Active topics


» » »

All times are UTC+03:00



Post new topic  Reply to topic  Page 11 of 13
  [ 184 posts ]  Go to page Previous 1 … 9 10 11 12 13 Next
  Print view Previous topic | Next topic 
Author Message
Mario_r4
PostPosted: Sun Dec 01, 2013 6:12 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
0CodErr wrote:
а зачем это нужно в буфере обмена? Какая ядру разница?

Ядру разницы нет, но есть разница приложениям. Внутри себя они могут использовать все что душе программиста угодно, но вот в буфер засылать все что угодно - это создавать лишние проблемы. Так что лучше определиться со стандартом заранее, чтобы не было неожиданных сюрпризов.
0CodErr wrote:
Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).

Лишний геморрой с дополнительными данными. Лучше уж единообразие для всех без исключения.

З.Ы. Также если сделать требование следовать одному стандарту, не придется писать лишний код, учитывающий все возможные варианты.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
0CodErr
PostPosted: Sun Dec 01, 2013 7:02 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.
Top
   
Reply with quote  
Mario_r4
PostPosted: Sun Dec 01, 2013 7:27 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
0CodErr wrote:
Mario_r4, тогда есть вероятность, что придётся перед копированием в буфер обмена преобразовывать в единственно верный формат. Потому что файлы с различными EOL уже и так существуют, хотим мы этого или нет.

Да, но не нужно тащить этот же бардак в реализацию буфера обмена. И придется преобразовывать только отличающиеся форматы. В Tinypad придется в любом случае преобразовывать, по причине собственного формата хранения во внутреннем буфере приложения. Я вообще склоняюсь к мысли остановиться на символе 0x0d (код 13) это все же даст некоторую экономию памяти, по сравнению с 0x0d 0x0a ну больших кусках текста.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
hidnplayr
PostPosted: Sun Dec 01, 2013 8:28 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1248
0CodErr wrote:
Mario_r4, а зачем это нужно в буфере обмена? Какая ядру разница?
Mario_r4 wrote:
Статья на википедии утверждает, что для надежности нужно использовать 0x0d 0x0a.
Я думаю, надо делать надёжно.
Или, как вариант, указывать тип содержимого(что-то вроде TEXT_CR, TEXT_LF, TEXT_CR_LF).


Text with only CR is nonsense.
To me it seems very simple, when writing text, use CR LF (for compatibility)
When reading text, parse only LF and ignore CR.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Top
   
Reply with quote  
Mario_r4
PostPosted: Sun Dec 01, 2013 8:47 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
hidnplayr wrote:
To me it seems very simple, when writing text, use CR LF (for compatibility)
When reading text, parse only LF and ignore CR.

Why? After all, to any program we add support for clipboard from scratch. There is no established standard already. However, if we use 1 byte instead of 2 bytes, then a large amount of text, we can get savings of memory.

On the other hand, if the use of 2 byte code will simplify working with the clipboard, we can leave 2 bytes . I'm still thinking.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
hidnplayr
PostPosted: Sun Dec 01, 2013 9:20 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1248
Mario_r4 wrote:
hidnplayr wrote:
To me it seems very simple, when writing text, use CR LF (for compatibility)
When reading text, parse only LF and ignore CR.

Why? After all, to any program we add support for clipboard from scratch. There is no established standard already. However, if we use 1 byte instead of 2 bytes, then a large amount of text, we can get savings of memory.

On the other hand, if the use of 2 byte code will simplify working with the clipboard, we can leave 2 bytes . I'm still thinking.


Any program should accept any encoding, this has nothing to do with clipboard.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Top
   
Reply with quote  
Mario_r4
PostPosted: Sun Dec 01, 2013 9:40 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
hidnplayr wrote:
Any program should accept any encoding, this has nothing to do with clipboard.

However, this increases the number of possible choices and therefore inflates code. I've come across in Windows with the situation where the standard Notepad does not understand line breaks. If the conditions for the buffer exchange would be more rigid, then such situations can be avoided in principle.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
0CodErr
PostPosted: Sun Dec 01, 2013 9:42 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
hidnplayr wrote:
Text with only CR is nonsense.
For example:http://en.wikipedia.org/wiki/End_of_line#Representations
Quote:
    LF: Multics, Unix and Unix-like systems (GNU/Linux, OS X, FreeBSD, AIX, Xenix, etc.), BeOS, Amiga, RISC OS and others.
    CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS, Amstrad CPC
    LF+CR: Acorn BBC and RISC OS spooled text output.
    CR: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
    RS: QNX pre-POSIX implementation.
I'm not sure, maybe it actually nonsense.
Top
   
Reply with quote  
hidnplayr
PostPosted: Sun Dec 01, 2013 9:57 pm 
Offline
Mentor/Kernel Developer
User avatar

Joined: Fri Jun 30, 2006 9:01 am
Posts: 1248
0CodErr wrote:
hidnplayr wrote:
Text with only CR is nonsense.
For example:http://en.wikipedia.org/wiki/End_of_line#Representations
Quote:
    LF: Multics, Unix and Unix-like systems (GNU/Linux, OS X, FreeBSD, AIX, Xenix, etc.), BeOS, Amiga, RISC OS and others.
    CR+LF: Microsoft Windows, DEC TOPS-10, RT-11 and most other early non-Unix and non-IBM OSes, CP/M, MP/M, DOS (MS-DOS, PC DOS, etc.), Atari TOS, OS/2, Symbian OS, Palm OS, Amstrad CPC
    LF+CR: Acorn BBC and RISC OS spooled text output.
    CR: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Mac OS up to version 9 and OS-9
    RS: QNX pre-POSIX implementation.
I'm not sure, maybe it actually nonsense.


MAC OS 9 was discontinued in 2002, should we still care? maybe.. maybe not :)

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Top
   
Reply with quote  
Freeman
PostPosted: Sun Dec 01, 2013 11:35 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
Mario_r4
If you want single-byte line break, single LF (Unix style) is better than single CR (Mac style), unless you also want to define your own, incompatible, Kolibri-only format, assumes programs must be written from scratch or specially adopted to Kolibri.

_________________
Разработчик языка программирования Кантор
Top
   
Reply with quote  
Mario_r4
PostPosted: Mon Dec 02, 2013 12:03 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Ok, let the majority will be right again - I'm tired of arguing with you guys. Time will heal all.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
Mario_r4
PostPosted: Wed Dec 11, 2013 10:41 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
SVN r.4343 - изменил документацию, добавил текст с блочным выделением.
Attachment:
clipboard_container_rus.txt [1.69 KiB]
Downloaded 173 times

Attachment:
clipboard_container_eng.txt [1.08 KiB]
Downloaded 163 times

Если кто может подправить мой кривоватый английский перевод, то просьба сделать, можно даже на SVN сразу.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
punk_joker
PostPosted: Thu Jan 02, 2014 1:04 am 
Offline

Joined: Tue Apr 12, 2011 11:19 pm
Posts: 1151
А нумерация слотов идет с нуля или единицы?

_________________
я лишь учусь
Top
   
Reply with quote  
Mario_r4
PostPosted: Thu Jan 02, 2014 1:09 am 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
punk_joker wrote:
А нумерация слотов идет с нуля или единицы?

С нуля разумеется. Я же программист, а не гуманитарий. :mrgreen:

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Top
   
Reply with quote  
punk_joker
PostPosted: Thu Jan 02, 2014 1:46 am 
Offline

Joined: Tue Apr 12, 2011 11:19 pm
Posts: 1151
Если я правильно понял, то при записи номер слота не указывается, но при чтении его указать необходимо. В какой слот тогда происходит запись?

Spoiler: Show
======================================================================
====================== Функция 54, подфункция 2 ======================
================== Считать данные из буфера обмена. ==================
======================================================================
Параметры:
* eax = 54 - номер функции
* ebx = 2 - номер подфункции
* eсx = номер слота
* edx = не используется, оставлено для единообразия
* esi = указатель на буфер под копируемые данные
Возвращаемое значение:
* eax = 0 - успешно
* eax = 1 - ошибка
* eax = -1 - отсутствует область главного списка

======================================================================
====================== Функция 54, подфункция 3 ======================
================== Записать данные в буфер обмена. ===================
======================================================================
Параметры:
* eax = 54 - номер функции
* ebx = 3 - номер подфункции
* eсx = не используется, оставлено для единообразия
* edx = количество копируемых байт
* esi = указатель на буфер под копируемые данные
Возвращаемое значение:
* eax = 0 - успешно
* eax = 1 - ошибка
* eax = -1 - отсутствует область главного списка

_________________
я лишь учусь
Top
   
Reply with quote  
Display posts from previous:  Sort by  
Post new topic  Reply to topic  Page 11 of 13
  [ 184 posts ]  Go to page Previous 1 … 9 10 11 12 13 Next

» » »

All times are UTC+03:00

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited