Board.KolibriOS.org

Mario79
Эту DLL можно было как раз и включить в общую папку дистрибутива.

andrew_programmer
Насколько это понял я, тебе предложили засунуть все компоненты в одну DLL, а не делать отдельную DLL для каждого из них (что было бы маразмом)

mike.dld
Этот маразм предложил я, а не он.

Внимание!
Объявление.

Пре6длагаю ВСЕМ разработчикам GUI объединить свои наработки и усилия в одну единую, стандартную DLL.А имеено в libGUI.Естествеено с сохранением всех авторских прав программистов.

Зачем объединять в одну DLL, а не делать каждый свою ?

А дело в том,что совместными усилиями мы сделаем оптимальную GUI библиотеку и программистам не придётся перестраиваться под GUI наработки разных разработчиков.


Я дошёл до того момента, когда мне нужно писать под Колибри приложения с УДОБНЫМ и СТАНДАРТНЫМ интерфейсом.Поэтому я продолжаю свои наработки по GUI прямо во время учебного семестра.Потомучто мне для моей научной программы( spektr ) необходим удобный интерфейс.

Это правильное решение и я поддреживаю эту идею )) Необходимо завести на svn ветку libGUI. Я перемещу туда все свои наработки.

andrew_programmer
Если делать общую ДЛЛ то надо стандартизировать интерфейс к контролам, т.е. чтобы все функции для работы с ними были похожи - создание, удаление, установка размеров, перерисовка и т.п.

andrew_programmer
Я за.
Serge
Согласен.

Для такой библиотеки своя malloc понадобится чтобы память под контролы выделять. Я скоро доделаю dlmalloc для приложений можно будет её включить в библиотеку.

Serge
А я выделяю в своих библиотеках память функцией 68.12. Чем плох такой подход?

YELLOW
Она выделяет память страничными блоками. Если надо выделить немного то будет большой перерасход. Это как VirualAlloc() в Win, если надо выделить много то в самый раз а как замена new и malloc нет. malloc будет запрашивать блок у системы через 68.12 и дальше отщипывать у него. Если блок освободится она вернёт его ядру.

В этом отношении не спорю. В одной из процедур мне нужен блок в 54 байта а выделяется 4к, что конечно многовато.

>Если делать общую ДЛЛ то надо стандартизировать интерфейс к контролам, т.е. чтобы все функции для работы с ними были похожи - создание, удаление, установка размеров, перерисовка и т.п.

Serge, ты предугадал мою первую тему для обсуждения.

Итак, начинаем.

Параметры компоненту можно передавать ввиде указателя на структуру.Структура специфична для каждого вида компонентов.Я предлагаю передавать указатель на структуру через стек.

1)Создание компонента.

В моих наработках по скролерам и кнопкам инициализация происходит при первом вызове контрола.Через стек передаётся указатель на структуру.Происходит инициализация компонента и устанавливается флаг о том, что контрол был инициализирован(флаг храниться в структуре пердаваемой контролу).Во время инициализации компонент перерисовывается полностью.

Можно инициализировать как делал я, а можно для каждого GUI компонента сделать отдельную функцию для инициализации.

Как посткпим с инициализацией ?

2)Удаление.

Можно возложить эту роль на сам компонент, а можно сделать отдельную функцию для каждого компонента.

3)Установка размеров.
Мой вариант.
Установка размеров компонента происходит во время инициализации компонента, когда в структуру, специфичную для каждого GUI компонента происходит занесение информации.А потом эта структура передаётся самому компоненту, который и производит инициализацию.
А какой вариант предлагаете вы ?

4)Перерисовка компонента.

Как это реализовано у меня.
Вся информация о сотоянии компонента: его инициализации, активности или не активности, разрешение на перерисовку, и т.д. храниться в специальном байте, находящимся в структуре, передаваемой компоненту.
При изменении состояний мыши в этом байте устанавливаются соответствующие биты и происходит вызов компонента.По сотоянию битов и координат мыши компонент судит о том, нужно ли производить перерисовку или нет.И нужно ли во время перерисовки компонента перерисовавать его полностью, а не только активную часть.

А что предлагаете вы ?

Обсуждаем.

andrew_programmer
1) Отдельная функция для инициализации каждого вида компонентов или одного компонента. Поясни, пожайлуста, а то имхо не совсем понятно. Передачу параметров лучше реализовать через стек чтобы можно было использовать STDCALL.

2) Лучше отдельную функцию.

3) Нормальный вариант. Надо только будет сделать функцию изменения размера компонента после его создания.

4) Тоже вполне логично.

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

Serge
Что мешает программисту создавать и использовать собственные сообщения в программе. Ведь без этого управлять многокомпонентной системой будет сложно.

> Отдельная функция для инициализации каждого вида компонентов или одного компонента. Поясни, пожайлуста, а то имхо не совсем понятно.

Лучше забыть про этот вариант.Он негодиться.

>Еще надо подумать над тем, как прозрачно реализовать создание большого числа компонентов. Например реализовать массив структур, т.е. при создании компонента создается необходимая структура, а пользователю возвращается только указатель на нее и дальнейшее взаимодействие с компонентом происходит через указатель.

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

Интересно, что скажет <Lrz> по поводу всего этого.

Поддерживаю, у меня в нынешней реализации указатель на информационную структуру передается через edi и смещением можно добраться до любого значения.
Вот пример:

macro version_op           ;для совместимости со старыми версиями optionbox все цвета задаются ручками
{
op_struc_size=26
option_group equ [edi]
op_left equ [edi+4]    ;координата начала рисования по х
op_top equ [edi+6]   ;координата начала рисования по у
op_color equ [edi+8]
op_border_color equ [edi+12] ; or [edi+4] ;цвет рамки checkbox ее можно задать самостоятельно
op_text_color equ   [edi+16];[edi+4]  ;цвет текста
op_text_ptr equ [edi+20]    ;указатель на начало текстовой строки 
op_text_length equ [edi+24] ;длина надписи (2^64 такой длины может быть текст)
}

macro   version_op1        ;продвинутая версия, использует цвета скина. 
{
op_struc_size=14
option_group equ [edi]
op_left equ [edi+4]    ;координата начала рисования по х
op_top equ [edi+6]   ;координата начала рисования по у
op_color equ [sc.work] ;
op_border_color equ [sc.work_graph] ; or [edi+4] ;цвет рамки checkbox ее можно задать самостоятельно
op_text_color equ   [sc.work_text];[edi+4]  ;цвет текста
op_text_ptr equ [edi+8]    ;указатель на начало текстовой строки 
op_text_length equ [edi+12] ;длина надписи (2^64 такой длины может быть текст)
}

И обработчик

macro draw_option_boxes start,end   ;рисовать чек боксы
{
   mov   edi,start         ;Указатель на начало данных чек боксов т.е. на начало данных первого чекбокса
   mov   ecx,((end-start)/op_struc_size) ;Количество чек боксов
@@:
   call   option_box.draw                  ;Отобразить чек бокс
   add   edi,op_struc_size               ;Указатель на последующие чек боксы  т.е. +28
   loop   @b   ;прыгнуть если в ecx/cx значение не 0 на верхнюю @@
}

Создание компонента: Как я понимаю. Создаем компонент копируем из DLL в выделеную память функции и потом передаем этим функциям параметры, а они уже обрабатывают их. Создание компонента в этом случае - инициализация памяти, копирование и передача параметров, начальная прорисовка компонента. Удаление это просто особождение памяти, выделеная для копирования функций обработки. Т.е удаление занимается отдельная функция. Хотя в большинстве случаев она просто будет срабатывать при завершении приложения, просто отдавая системе всю свободную память. Еще очень важно все свои данные компоненты хранят отдельно от кода. Т.е. необходимо добиться что бы один код обрабатывал сколь угодно компонентов, на пример как это сделано в checkbox,editbox,optionbox(radiobatton).

3) Размеры задаются во время инициализации, как и предлагаешь ты, но так же нужно предусмотреть изменение размеров компонента, в моих компонентах, мне достаточно поменять зачения в структуре и перерисовать компонент.
4) Согласен