Общесистемный буфер обмена

Internal structure and you change requests/suggestions
  • Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.
    IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра. В нынешнем ядре реализовать буфер можно за пару часов с отладкой.

    P.S. viewtopic.php?p=9987#p9987
  • согласен с Serge.. к чему тема - я не в состоянии этого реализовать, а сделать эно нужно.. вот и обращаюсь к вам, ядерщикам..
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Да, эта тема снова всплывает, но как я уже выразился, имхо, это усложнение ядра. Я не сторонник того, что бы ядро содержало и буфер обмена и gui интерфейс и частично драйвера устройств и т.д. Мне бы не хотелось делать лишнюю работу, и переписывать потом "нормально".
  • Вот именно из-за того, что все мнения по буферу обмена разделялись на сторонников реализации буфера при помощи ядра и на сторонников реализации буфера как приложения, все обсуждения по буферу обмена заканчивались ничем.

    В конце концов надо аргументировать свои варианты. И подходить ко всему без предубеждений. Но даже в спорных ситуациях нужно находить компромисное решение, иначе будет как в басне Крылова,-"А воз и ныне там.".

    Мне так кажется, что у разных людей, занимающихся ядром, разное видение каким должно быть ядро KolibriOS. Одни смотрят в сторону микроядра, стараясь всё что можно убрать из него, а другие смотрят в сторону гибридного ядра,оставляя в ядре часть драйверов, и делая другие драйверы динамическими.

    В общем нужно одно единое мнение, иначе так и будут всякие разногласия в подходах.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Как однажды высказался diamond:
    - Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
    От сюда следует правило, если у человека есть реальная потребность и он сделает буфер обмена. Его мнение приоритетнее все тех кто просто болтает. Но ИМХО конечное видение системы должно быть единым! Иначе одни будут писать, другие потом переписывать...
  • >> - Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
    Золотые слова, остальное в теме болтовня.
    Из хаоса в космос
  • Serge wrote:Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.
    Вообще-то без ядра ничего не реализовать, что касается любого вида IPC!
    Serge wrote: IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра.
    Судя по тому что ты написал выше, то оконная система пожизни будет ядерной, т.к. любое взаимодействие процессов (а приложения как то должны общаться с оконной системой) происходит просредством ядра.

    Тогда в любом слачуе пихаем в ядро, просто в оконной системе "будет тот же самый буфер в ядре только в другой упаковке и с другим названием" :)
    Serge wrote: В нынешнем ядре реализовать буфер можно за пару часов с отладкой.
    Полностью согласен.
  • Кстати для работы черес IPC надо знать PID сервиса.
    Гарантировать что у clipboard будет постоянный PID в разных версиях ядра и дистрибутивах сложно. Остаётся после запуска сервиса записывать его PID в файл /rd/1/clipboard_pid_please_dont_delete_me. Но если отказаться от рам-диска то и этот способ перестанет работать.

    Тому кто собирается делать clipboard стоит почитать MSDN. Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.
  • Serge
    Кстати для работы черес IPC надо знать PID сервиса.
    А что если зарезервировать ряд PIDов (скажем до 100) под системные сервисы, каждый PID будет строго регламенгтирован по назначению, а соответствующая ему прога будет запускаться скажем спецфункцией ядра из таблицы сервисов, или конфигурационного файла. А обращаться к сервису либо через IPC, либо добавить более шуструю функцию сообщений (возможно с автозапуском сервиса, если не запущен). Это может быть полезно не только для буфера обмена, но и для других расширений системы.
    Заглянул на огонёк
  • или резервировать под ядро прерывания, как это сделано в ДОС
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Serge wrote:Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.
    Можно, кстати, пока продумать программный интерфейс для работы с буфером обмена.
    Он то не должен зависеть от реализации.
    Serge wrote:Кстати для работы через IPC надо знать PID сервиса.
    Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросом
    "Кто из вас Clipboard?". Ядро должно разослать это сообщение всем процессам.
    А процесс Clipboard ответит спросившему приложению.

    Вот, IMHO, интересная статья: http://rsdn.ru/article/baseserv/ipc.xml
  • Есть такая идея тип данных вообще не хранить в буфере, если какой-то компонент принимает из буфера данные он сам должен знать что за тип там лежит, т.е. читать байты из буфера и если их удалось преобразовать в нужный формат то - буфер не пус иначе - пуст. Ну а сам буфер реализовать как демон.
    Надо воспользоватся функцией посылки сообщения для передачи данных между процессами. Все это сейчас можно сделать и на С (если только сделать функции get_message для пирема сообщений, set_property для установки перенменной окружения - в которой будет хранится значение PID демона, get_property ну и int get_currend_process_pid)

    Для демона буфера обмена предлогаю зарезивировать сообщения с номерами:
    CB000000h - послать в буфер обмена данные
    000000CBh - принять данные из буфера обмена.

    Которые посылать с помощью
    void stdcall _ksys_set_wanted_events(int ev);

    А код демона приблизительно такой (в самом примитивном варианте):

    Code: Select all

    #include <kolibrisys.h>
    #include <stdlib.h>
    #include <string.h> 
    
    #define TO_CLIBOARD CB000000h;
    #define OUT_CLIBOARD  000000CBh;
    
    void kos_Main()
    {
               int datasize = 0;
               unsigned char *buf;
      
              // Поставить переменную окруженя CLIPBOARD чтобы все знали на какой PID посылать сообщение 
               _ksys_set_property( "CLIPBOARD", itoa( get_currend_process_pid() ) );
    
    	while(1)
    	{
                   start: 
    		switch (_ksys_wait_for_event_infinite())
    		{
                             case TO_CLIBOARD:
                                  buf = _ksys_get_message(&datasize); // сообщение в память                  
                                   goto start;    
                             case OUT_CLIBOARD:
                                  int size, *pid = _ksys_get_message(&size); // принять пид получателя
                                 _ksys_send_message(*pid, buf, datasize);// послать ему данные
                                 goto start; 
    		}
    	}
    }
    
    Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
  • > Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросом

    Хм...а не слишком ли тяжело?
    По поводу прерываний. Можно резервировать не прерывание, а системную ф-цию.
    Типа ядро предоставляет такой себе сервис буфера обмена. Какое-либо приложение может зарегистрировать себя как менеджер буфера обмена. Теперь ядро знает кому форвардить GET/SET clipboard.
    Вот только другой вопрос, соит ли оно того? Чем все выше изложеные методы лучше чем буфер обмена в ядре?
    Возможно стоит задуматься о резервировании PID'ов, но что-то мне в этой идее не нравится :)

    > Есть такая идея тип данных вообще не хранить в буфере...
    Не разумно. Простой пример - RTF и plain-text. При копировании RTF в буфер заносится 2 копии (вроде бы) RTF и plain-text. Это нужно для того, чтобы приложение могло получить и форматированный текст, если поддерживает его и простой текст, если форматирование не поддерживается. Возможно для экономии памяти лежит одна копия, просто clipboard сам стрипает символы форматирования, в реализацию не вникал. Это раз.
    Во вторых, не разумно каждый раз анализировать содержимое буфера.
    В-третьих, где гарантия что plain-text в буфере это не картинка? Хидеры? так зачем выдумывать хидеры если можно один раз задать тип и все.
    В-четвертых. А как быть с файлами? При копировании файла в буфер заносится лишь путь к файлу.
    И т.д.
  • Сделать системную ф-цию было бы хорошо. Потому что тогда работа с буфером будет стандартной и не потребуется дополнительных программ. Но данной реализацией, по моему мнению, должны заниматься разработчики ядра.

    Я вижу это так:
    В ebx можно передавать адрес такой структуры:

    dd ; номер подфункции (считать, записать)
    dd ; тип содержимого (текст, битмап, список файлов)
    dd ; объём содержимого в байтах
    dd ; адрес, по которому располагаются данные

    Список файлов можно сделать как в винде - файлы разделяются нулями, список заканчивается двойным нулём. Работать с таким списком очень удобно. И ещё хочу пояснить, что под словом "битмап" я понимаю файл bmp, а не только данные. Потому что из него можно извлечь размеры и глубину цвета.
  • Who is online

    Users browsing this forum: No registered users and 8 guests