Общесистемный буфер обмена
-
Перерисовывание всегда немного моргает из-за отсутствия вертикальной синхронизации, так что перерисовывать только при изменении содержимого буфера обмена.
Перерисовку по обновлению поставил, но:
-в newlibc вызов printf тянет за собой 20кб прочих зависимостей
-msgbox мягко говоря сложно использовать - нереентерабельная и немодальная библиотека
-попробовал задействовать ktcc - убил день на выяснение следующих фактов:
--компилятор tcc требует доработки - inline и некоторые ошибки в исходниках приводят к крэшу компилятора tcc
--не полностью совместимый с gcc встроенный ассемблер ktcc
--несовместимость с принципом gcc intrinsics приводит к тому, что библиотеки собранные gcc нельзя из ktcc использовать совсем (и скорее всего из других компиляторов тоже)
--libc от ktcc имеет свои ошибки где то в *printf, надо править или пробовать использовать ktcc с menuetlibc. И именование системных вызовов не совпадает с newlib
--нет формирования map файла, в итоге нормально пользовать отладчик нельзя
В итоге, пока оптимизация размера откладывается.
Отдельное окошко с подробностями добавлю как побеждю msglib или напишу аналог.
Upd. Все что надо, исправлено
-в newlibc вызов printf тянет за собой 20кб прочих зависимостей
-msgbox мягко говоря сложно использовать - нереентерабельная и немодальная библиотека
-попробовал задействовать ktcc - убил день на выяснение следующих фактов:
--компилятор tcc требует доработки - inline и некоторые ошибки в исходниках приводят к крэшу компилятора tcc
--не полностью совместимый с gcc встроенный ассемблер ktcc
--несовместимость с принципом gcc intrinsics приводит к тому, что библиотеки собранные gcc нельзя из ktcc использовать совсем (и скорее всего из других компиляторов тоже)
--libc от ktcc имеет свои ошибки где то в *printf, надо править или пробовать использовать ktcc с menuetlibc. И именование системных вызовов не совпадает с newlib
--нет формирования map файла, в итоге нормально пользовать отладчик нельзя
В итоге, пока оптимизация размера откладывается.
Отдельное окошко с подробностями добавлю как побеждю msglib или напишу аналог.
Upd. Все что надо, исправлено
Last edited by Siemargl on Fri Jun 10, 2016 7:07 pm, edited 1 time in total.
Попробуй С--, у него уже есть масса оберток для сисфункий и библиотек.
Программ для изучения тоже хватает.
Программ для изучения тоже хватает.
Из хаоса в космос
На мой взгляд, с-- выглядит достаточно дохлым языком (все съехали на LLVM), чтобы его учить.
Итого, пофиксил слегка ktcc (точнее его clib) и пересобрал им. Стало поменьше.
Добавил модальное окошко, при двойном щелчке на тексте.
Единственное - похоже баг в системе - через некоторое время (после запуска скринсейвера), сисфункция 54.1 начинает крашится при вызове.
Оживает ОС только по перезагрузке. Проявилось, т.к. я при каждой перерисовке перечитываю клипбоард.
Версия обновлена, уменьшен размер после сборки текущим tcc
Итого, пофиксил слегка ktcc (точнее его clib) и пересобрал им. Стало поменьше.
Добавил модальное окошко, при двойном щелчке на тексте.
Единственное - похоже баг в системе - через некоторое время (после запуска скринсейвера), сисфункция 54.1 начинает крашится при вызове.
Оживает ОС только по перезагрузке. Проявилось, т.к. я при каждой перерисовке перечитываю клипбоард.
Версия обновлена, уменьшен размер после сборки текущим tcc
- Attachments
-
-
clipview (7.59 KiB)Downloaded 556 times
-
ClipView_tcc_src.zip (9.77 KiB)Downloaded 533 times
-
Sounds very like to what I fixed in #8928.Siemargl wrote:Единственное - похоже баг в системе - через некоторое время (после запуска скринсейвера), сисфункция 54.1 начинает крашится при вызове.
Check the latest nightbuild.
Добрый день, нашел нестыковки в описании формата содержимого буфера обмена.
В программе clipwiev содержимое буфера описывается так:
а в описании системных функций то же самое выглядит так:
Нужно сделать везде одинаковое описание. Думаю что белее правильное описание в программе clipwiev где нет текста с блочным выделением а в изображении нет:
В программе clipwiev содержимое буфера описывается так:
Spoiler:
1. Первый dword содержит общую длину данных в контейнере
2. Второй dword указывает тип данныx:
0 = Текст
1 = Изображение
2 = RAW
4 и выше зарезервировано
2.1 Текст
Данные в третьем dword содержат тип кодировки:
0 = UTF
1 = 0866
2 = 1251
3 и выше зарезервировано
2.2 Изображение
Третий dword - размер по X
Четвертый dword - размер по Y
Пятый dword - глубина цвета в битах (8, 16, 24, 32, 48, 64)
Шестой dword - Указатель на палитру (смещение от начала файла).
Если палитры нет то значение 0
Седьмой dword - Размер области палитры, максимальное значение 256*4=1024байт.
Если палитры нет то значение 0
Восьмой dword - Указатель на данные пикселей для R, G, B.
Девятый dword - Размер области данных для пикселей.
2.3 RAW
Может содержать любые данные, т.к. содержимое на усмотрение программиста
Spoiler:
1. Первый dword содержит общую длину данных в контейнере
2. Второй dword указывает тип данныx:
0 = Текст
1 = Изображение
2 = RAW
3 = путь для файлового менеджера Eolite
4 и выше зарезервировано
2.1 Текст
Данные в третьем dword содержат тип:
0 = UTF
1 = 0866::
2 = 1251
3 и выше зарезервировано
2.2 Изображение
Третий dword - размер по X
Четвертый dword - размер по Y
Пятый dword - глубина цвета в битах (8, 16, 24, 32, 48, 64)
Шестой dword - Указатель на палитру (смещение от начала файла).
Если палитры нет то значение 0
Седьмой dword - Размер области палитры, максимальное значение 256*4=1024байт.
Если палитры нет то значение 0
Восьмой dword - Указатель на данные пикселей для R, G, B.
Девятый dword - Размер области данных для пикселей.
2.3 RAW
Может содержать любые данные, т.к. содержимое на усмотрение программиста
2.4 Путь для файлового менеджера
В отличии от остальных данных, для файлового менеджера используется word содержащий константу 0x0001, после этого значения находится путь к копируемой директории или файлу
Восьмой dword - Указатель на данные пикселей для R, G, B.
Девятый dword - Размер области данных для пикселей.
Есть некоторые сомнения по функционированию описания буфера обмена для изображений: Насколько я смотрел код ядра, буфер обмена просто копирует кусок памяти приложения в ядерную память, без какого либо анализа содержимого. + к этому вносит сомнения фраза
"(смещение от начала файла)."
"(смещение от начала файла)."
Who is online
Users browsing this forum: No registered users and 1 guest