Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Dec 08, 2019 6:41 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 184 posts ]  Go to page Previous 15 6 7 8 913 Next
Author Message
PostPosted: Fri Dec 07, 2012 11:14 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
johnfound
Прозрачно может быть только в одном случае - гребём из буфера всё сразу не разбираясь с размером данных. Но в этом случае место под данные должно выделять ядро, потому что только оно знает размер. Выделение памяти ядром немного громоздкая операция.


Top
   
PostPosted: Sat Dec 08, 2012 1:13 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Ну вот предлагаю так:
Code:
OpenClipboard
Read/Write/Clear/GetInfoClipboard
CloseClipboard


OpenClipboard - блокирует буфер только для этого приложения. CloseClipboard - разблокирует. Только надо чтобы было максимальное время в пределах которого можно вызывать остальные функции. Иначе ядро закрывает буфер и на запросы приложения отвечает ошибкой.


Top
   
PostPosted: Sat Dec 08, 2012 9:23 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Можно и без блокировки для чтения.
Приложение создаёт буфер 68.12 и передаёт ядру указатель и размер. Ядро при необходимости увеличит размер буфера или создаст новый. Когда буфер будет ненужен приложение освободит его. Надо только учитывать что после вызова функции адрес буфера может поменяться.


Top
   
PostPosted: Sat Dec 08, 2012 11:15 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Serge, чем проще (для использования), тем лучше.
Использовать 68.11 не стоит - это ограничит использование буфера обмена только для приложения которые не используют ф.64
Лучше блокировать буфер явно. Кстати, в Windows именно так и сделано и работает вполне хорошо.


Top
   
PostPosted: Sat Dec 08, 2012 12:43 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Чёртов файрфокс упал и убил стену текста :evil:


Top
   
PostPosted: Sat Dec 08, 2012 6:34 pm 
Offline

Joined: Sun Oct 30, 2011 6:43 pm
Posts: 1499
А если так:

Подфункция 2: Прочитать из буфера
ebx = 2
ecx = размер буфера-приёмника
edx = тип данных
edi = указатель на буфер-приёмник

Если в буфере есть запрашиваемый тип данных, то
скопировать данные
вернуть успех
Иначе
вернуть ошибку.

Количество одновременно хранимых данных разных типов
ядро определяет в зависимости от размера этих данных
и размера свободной памяти.

Приложение создаёт буфер с запасом в зависимости от данных, так как
приложение знает, с данными какого размера оно хочет и может работать.

Если же всё-таки размер буфера-приёмника окажется меньше, чем размер данных, то
вернуть ошибку и размер данных.
Если приложение захочет, то оно сделает новый запрос с учётом этого размера.


Top
   
PostPosted: Sat Dec 08, 2012 11:58 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
johnfound
ф64. не позволяет загружать длл и другие ограничения у неё есть. К тому же она легко эмулируется набором 68.12 и 68.26.

read_clipboard:
in:
eax = ?
ebx = ?
ecx = buffer
edx = format
out:
eax = size
edx = buffer

Самый простой вариант > 90% случаев
Code:
/*    somwhere in .bss   */

void *buffer;
int   size;

/*    main code          */

    buffer = read_clipboard(buffer, &size, format);
    if( size != 0 )
    {
        profit();
    }

Bce операции с блокировками и памятью выполняет ядро. Если приложение передаёт ненулевой указатель то буфер должен быть создан 68.12.

Если приложение умеет вставлять не только текст
Code:
    if( open_clipboard() )
    {
        get_clipborad_info(&info_text, FORMAT_TEXT);
        get_clipborad_info(&info_bitmap, FORMAT_BITMAP);
        get_clipborad_info(&info_raw, FORMAT_RAW);

        do_something();

        buffer = read_clipboard(buffer, &size, format);

        if( size != 0 )
        {
            do_even_more();
            profit();
        }
        close_clipboard();
    }
После обработки буфера приложение может его сохранить, удалить , изменить размер, или вернуть физические страницы ядру.


Top
   
PostPosted: Sun Dec 09, 2012 1:49 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Serge, мне твои разсуждения напоминают на Linux с котором мучаюсь напоследок. Там можно конечно делать потоки через sys_clone, но если хочется использовать xlib, то обязательно надо использовать pthreads, а память выделять через libc иначе не работает.
Дизаин системы нужно обдумывать внимательно чтобы не допускать ненужные зависимости.


Top
   
PostPosted: Sun Dec 09, 2012 9:48 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
johnfound
ф.68 всё же ядерные функции, а не libc. А ф.64 давно устарела.
Quote:
Дизаин системы нужно обдумывать внимательно чтобы не допускать ненужные зависимости.
Этим и занимаемся. Пусть отпишутся те, кому этот буфер нужен.


Top
   
PostPosted: Sun Dec 09, 2012 11:17 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Мне нужен. :) Для консольных утилит, и всех остальных тоже.


Top
   
PostPosted: Sun Dec 09, 2012 12:09 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Отпишутся в смысле что они думают по поводу API. И про кодировку текста. Использовать unicode или нет ?


Top
   
PostPosted: Sun Dec 09, 2012 12:58 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
Мне нужен для FreshLib. FreshLib работает только в UTF-8. Но мне кажется, что ядро не надо знать ничего о данных в буфере. Только надо объявить стандартные типы данных чтобы все пользовались им, а не придумывали каждый свои. И вот в этих кодов будут и TEXT_WIN1251 и TEXT_UTF8 и т.д. (кстати я назвал бы их: cltTextWin1251 и cltTextUtf8 :) )


Last edited by johnfound on Sun Dec 09, 2012 1:48 pm, edited 1 time in total.

Top
   
PostPosted: Sun Dec 09, 2012 1:05 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
Мне кажется, что оптимальный вариант - две подфункции.

1) Поместить данные в буфер. Через структуру.
dd type
dd size
dd address

2) Получить данные из буфера. Через ту же структуру. Буфер не очищается.

Преимущества: не нужно делать проверку перед тем, как забрать данные из буфера; скорее всего не нужно блокировать буфер (вытекает из первого); простота использования (например, установка type = 0 означает очистку буфера).
Недостатки: type для каждого типа данных должно быть уникальным; пока не могу ничего сказать о расширяемости возможностей данной функции.


Top
   
PostPosted: Sun Dec 09, 2012 1:59 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
johnfound
Всё же кодировка для текста должна быть единственной. Иначе к каждой программе надо будет цеплять конвертер на все возможные варианты.


Top
   
PostPosted: Sun Dec 09, 2012 2:43 pm 
Offline

Joined: Tue Jul 26, 2011 11:03 pm
Posts: 62
Serge wrote:
Можно и без блокировки для чтения.
Приложение создаёт буфер 68.12 и передаёт ядру указатель и размер. Ядро при необходимости увеличит размер буфера или создаст новый. Когда буфер будет ненужен приложение освободит его. Надо только учитывать что после вызова функции адрес буфера может поменяться.
Ядро создаёт буфер и передаёт во владение приложению. Когда буфер будет ненужен приложение освободит его. Такое технически возможно в даный момент?

Нельзя давать право приложению дёргать ф-цию для чтения буфера когда хочет. Только когда пользователь нажал ctrl+c в одном окне и ctrl+v вдругом. И ядро будет разбираться со всеми указателями и размерами. А если приложение хочет в другой буфер то оно может скопировать или попросить ядро перемапить для больших размеров.

Сама ф-ция чтение буфера вприципе-то не нужна за исключение когда размер скопировано превышает размер доступной памяти

Приложение посылает данные в буфер обмена если какая-то глобальная комбинация клавиш нажата. И если другая глобальная комбинация нажата в окне в фокусе то окно получает право читать из буфера для текужего ID.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 184 posts ]  Go to page Previous 15 6 7 8 913 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