Board.KolibriOS.org

Библиотека libGUI с реализоваными контролами(элементами управления).
http://www.menuetosgame.narod.ru/programs/libGUI.7z

Документация для GUI разработчиков в архиве.
Демка(она же и пример использования контролов) запускается из любой директории.Гдавное, чтобы DLL-ка libGUI.obj находилась в той-же дериктории, что и демка.

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

Мне понравилось, я сейчас заканчиваю очередное переписывание editbox, и затем добавлю в библиотеку компоненты checkbox и radiobutton. (Editbox находиться пока в незавершенном состоянии). Еще один вопрос демки можно будет когда - нить перемещать по экрану ?

<Lrz>
В последнем архиве они перемещаются.

http://www.menuetosgame.narod.ru/programs/libGUI.7z
Скачал, попробовал под эмулятором перемещать демо, ничего не получилось. Поробовал закрыть приложение мышкой, не получилось. Закрыл только по Alt+F4

<Lrz>
Я лично из этого архива запускал в эмуляторе, и все перемещалось. Может у тебя в пути присутствуют русские символы?

У меня есть одно предложение. В разработке editbox я продвинулся до того момента когда, возникла возможность в реализации функций copy and paste. (ctrl+c; ctrl+v). Но мне хотелось, что бы вставки контекста были доступны и другим приложениям(программам). Я думаю написать сервис, который будет находиться в памяти, а программы, в которых будет эта поддержка будут работать через него и соответсвтенно копировать контент. Релаизация возможно такая:
Вот предполагаемый формат, очень похож на XML
<сору ver 1.0>
<text cp=1251, color 0x0, ....>
Копируемый текст
</text>
Т.е. при копировании будет оформляться вот такая структура и передаваться запущеному сервису, а он в свою очередь будет перенаправлять другой программе при вызове ctrl+v.
Если есть у кого предложения, прошу высказаться.

> <text
Если речь про системный буфер обмена, то должен быть предусмотрен также тип image - изображение (участок изображения) в формате bmp или raw

Безусловно, просто нужно разработать стандарт и оформить его. Я предлагаю сделать стандарт расширяемым, с поддержкой image bmp или raw, и всего остального. Если этот стандарт будет поддрежан, то в дальнейшем вожможно будет разрабатывать приложения, подключать необходимые модули и не думать о совместимости. Т.е. я предлагаю сделать контейнер на основе XML стандарта.

<Lrz>

Хорошая идея. Только зачем сервис ? Пусть это будут новые функции ядра, и скопированные данные будут храниться в общей памяти ядра.

Я против размещения всякой требухи в ядре. Ядро должно выполнять совершенно другие функции, а не обработку контейнера. Допустим запускаем программу, в которой есть компонент, который умеет работать с контейнером(необходимо будет сформировать контейнер) При запуске активируется сервис, который висит в трее(процесс), при CTRL+C формируется контейнер, а сервису передаются указатели на сформировавшийся контейнер (выделяется участок в памяти, в нем и происхоидит формирование). Далее, другая программа, по CRTL+V запрашивает у сервиса вставку содержимого и сервис, передает указатель на контейнер. Программа берет данные и преобразует их в удобочитаемый формат для себя и вставляет. Сервис по оформлению и вставке осуществляет dll-ка, которая подключается к программам, которые используют этот сервис.

<Lrz>
Serge дело говорит - на уровне ядра это будет проще сделать, так как IPC больно мудрено получается.

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

<Lrz>

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

XML хорошо. но 99% копируемой инормации - текст.
Я бы сделал так. Определить три типа данных: текст, картинка, и raw данные (контейнер (привет OLE)). Описание данных в XML сделать отдельной строкой и только для контейнеров.
Тогда copy получает четыре параметра: тип данных, XML-строку или ноль, указатель на данные и их размер.
Дальше выделяет необходимую память и копирует туда XML и даные.

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

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

clear уничтожит буфер если он занимет слишком много места.

Обновление libGUI.
http://www.menuetosgame.narod.ru/programs/libGUI.7z

Исправлен недочёт,связанный с crate_control(в остальном всё нормально).
Подкорректированы цвета для 2D кнопок.Теперь они выглядят объёмными при любом цвете скина.
Оптимизация кода для 2D объектов(кнопки и скролеры).Оптимизация проведена как по скорости, так и по размеру.
Демка теперь перемещается.

<Lrz>
Для выхода из демки используй кнопку Exit.

All
Дальше я решил заняться закладками.
Продумов много вариантов реализации, я решил, что самым оптимальным будет вариант, когда все контролы, находящиеся на закладках, будут дочерними по отношению к закладке.При переключении разных закладок сообщения от клавиатуры и мыши будут посылаться контролам, которые находятся на активной закладке.

Что касается обменного буфера, то я думаю, что вариант Serge-а самый лучший.От того, что в памяти ядра разместиться буфер обмена никакого вреда стабильности и безопасности системе не будет.

Неплохие компоненты. Давно пора было начать их писать, только чесслово слишком уж они по-виндовсавски смотрятся. Колибри - она маленькая вся, компактная.

Компоненты должны быть такими же по моему ИМХО.

А чего не кватает КолибриОС просто катастрофически - это окна выбора файла.