Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Jul 22, 2019 8:53 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Wed May 27, 2009 3:01 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Давно хотел этим заняться, но всё руки не доходили. В приложении - пример лэйаутов для Колибри (ссылка просто для ознакомления, никаких YAML и XML я не напридумывал). Сделал на скорую руку за пару дней три контрола: hbox_layout (собственно, он самый), rect (рисует свои границы красным) и spacer (ничего не рисует, но занимает место). Собственно, это черновой вариант, так что в код особо смотреть не нужно (за исключением example.asm) и бросаться использовать тоже.

Для проверки кода - собрать example.asm, запустить и поизменять размеры окна (будет видно, что размеры и положение "контролов" также меняются).

Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно). Жду-с комментариев товарищей гуи-строителей.


Attachments:
File comment: Layouts sample
layout.7z [7.36 KiB]
Downloaded 313 times

_________________
in code we trust
Top
   
PostPosted: Wed May 27, 2009 8:18 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
эх, а я (в программе, которая не увидела и не увидит свет) сам писал обработку изменения размеров окна).. Так что весчь нужная

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Wed May 27, 2009 8:45 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Правильной дорогой идем! Когда то я далал поделку, там небыло понятия лэйаут но вводился widget, в общем нужна какая то основа-абстракция.


Top
   
PostPosted: Wed May 27, 2009 9:19 am 
mike.dld
Quote:
Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно).

Все замечательно, даже наверное невзъебенно круто (разве что я по причине своего отсталого развития оценить не в состоянии), но меня мучает вопрос: Три года хватит?
Нет это не стеб, но уже какое начинание мегакрутое, а потом все тухнет и помирает - а между тем BOXLIB уже работает. Да оно не невзъебенно круто как все другие мегапроекты, но тем не менее - работает. И репу особо чесать над тем как использовать не нужно - берешь и подключаешь и все!

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


Top
   
PostPosted: Wed May 27, 2009 11:34 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Mario
Три года, я думаю, хватит. Возможно, хватит и меньше, но что уж мелочиться (зная наши темпы)...

_________________
in code we trust


Top
   
PostPosted: Thu May 28, 2009 8:30 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Немного более приближенный к реалиям вариант. Добавил vbox_layout, в результате стало возможным реализовать практически любой интерфейс.


Attachments:
File comment: Layout sample (v2)
layout2.7z [7.64 KiB]
Downloaded 274 times

_________________
in code we trust
Top
   
PostPosted: Thu May 28, 2009 10:42 pm 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 811
Эта программа что-то наподобие окна с фреймами?


Top
   
PostPosted: Fri May 29, 2009 6:20 am 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 752
это вроде как для построения интерфейса приложения как в GTK или Java.


Top
   
PostPosted: Wed Jun 03, 2009 2:46 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
mike.dld wrote:
Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно). Жду-с комментариев товарищей гуи-строителей

Ну, в общем-то, все понятно. За исключением назначения поля layout_t.sizing

Тут можно продолжить беседу на разных уровнях (в порядке значимости, имхо):
1) Представление о "правильности построения библиотеки GUI". У меня оно несколько другое, вытекающее из концепции земляка Кладова.
2) Можно принять текущую концепцию за аксиому, и говорить о рациональности построения структур данных. Мне кажется можно и "по-оптимальние"
3) А можно просто говорить про оптимизацию текущих конкретных кодов, считая структуры данных предопределенными.

mike.dld, интересуют ли Вас комментарии в таком стиле :?:
Если да, то на каком уровне: понятно же, что если мы ведем беседу по первому пункту, то остальное - не более, чем технические подробности реализации.......


Top
   
PostPosted: Thu Jun 04, 2009 1:35 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Собственно, правильность я согласен обсудить в отдельной ветке. Тут же интересует скорее второй пункт, и-то только в том случае, если твои взгляды отличаются не кардинально. Учитывая то, что ты упоминаешь Кладова (я так понимаю, речь о KOL&MCK), они всё таки различаются ощутимо, так как в Дельфи нет лэйаутов и используется другой (не лучший, ИМХО) способ дизайна UI. Про оптимизацию (третий пункт) говорить рано, это всегда успеется.

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

_________________
in code we trust


Top
   
PostPosted: Thu Jun 04, 2009 7:57 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
1) Ну сделайте ветку, интересно будет. Вы изложите схему, которая Вам кажется более естественной, ну а я - которую мне.
Может потом и симбиоз получится, превосходящий все сделанное до сих пор :)
Как минимум, понимать идеи друг друга - это есть хорошо

2) Продолжу вечером (сейчас на работу бегу)

3) Имел. В том виде, который Вы считаете не самым лучшим :)
Хотя, очень уж большой разницы не вижу - это способ обработки (в основном - ресайзингом) чего-то типа WM_SIZE, начиная с родителя. Тот или другой способ - не очень важно, вопросы рекурсий (например) все равно могут возникнуть.
Грубо говоря, сегодняшний Align в KOL - это мое исполнение.


Top
   
PostPosted: Thu Jun 04, 2009 10:14 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Нижеизложенное является не более, чем соображениями из серии: "я бы делал примерно так".
И ни в коем случае не фиксируют "некие баги" - их просто нет. А "соображения" - не меняют исходной функциональности.


1) В определении "класса" и vmt я бы убрал один уровень вложенности. Т.е. объект имеет указатель сразу на vmt, а уже именно в этой таблице: первым полем - адрес vmt предка, вторым - пускай будет адрес имени, далее - адреса виртуальных методов (кстати, первым методом обычно делают деструктор)

2) Настораживают два "параллельных" массива в layout_t: _.children и sizings
Мне кажется, вместо sizings типа ptr_array_t надо завести просто одно поле sizing типа dword внутри, может даже и widget_t - и всего делов-то

3) Про то, что "детишки" организованы в виде массива.
Мне кажется что удобнее делать их было в виде списка. Ну или как двунаправленный список. В букварях вроде рисуют сводные таблицы возможностей для эдаких (массивы, списки, двунаправленные, ассоциативные, и т.п.) структур данных.
Вроде бы: сверх быстрый доступ именно по индексу - не очень-то и нужен, перечисление - и в списках идет нормально, удаление и вставка элемента - могут и для произвольного элемента понадобиться, и тут списки как раз и выигрывают...
Получится, что некий контрол должен иметь два указателя - на своего "соседа", и на вход в цепочку "детишек". Ну или по "паре ссылок", для случая двунаправленных списков.
Мне кажется, это рациональнее, чем динамический объект, на который указует ptr_array_t

4) Не очень понятно применение widget_is_kind_of, если по большому счету-то. Я бы вообще наплевал на проверку классов. как следствие - могла бы оказаться ненужной и вся система RTTI.
Ну нет у контрола детишек, вот и нет перечисления.
Но, возможно, это уже следствие в "разности концепций" - надо чтобы класс widget_t содержал в vmt метод arrange_widgets. Т.е., все "классовое различие" начинает как бы и пропадать...
Не, ну я свято верю в то, что лучшее средство от перхоти - гильотина :)

5) Ну и совсем не принципиальное замечание, больше стилистического характера.
Вроде бы fasm позволяет наследовать структуры. Примерно так:
Code:
struct layout_t container_t
  sizings   ptr_array_t
  sizing    dd ? ; кто такой, почему не знаю...
  spacing   dd ?
ends
тогда не пришлось бы приводить один указатель к разным классам
Code:
        mov     esi, [ebx + layout_t.children] ; было container_t
        mov     edi, [ebx + layout_t.sizings]
Приведение к разным - напрягает. Особенно по-началу, когда иерархия классов в голове еще не твердо сидит.


=============================================================================
ЗЫ: если написал не очень понятно (немного наспех), ТО: на любой Ваш вопрос - любой наш ответ :)


Top
   
PostPosted: Sun Jun 07, 2009 9:35 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Извини, что поздновато.
  1. Согласен, это правильно.
  2. Учитывая то, что предпочтительным способом расположения виджетов в окне будут лэйауты, вероятно да, легче перенести sizing в widget_t.
  3. Согласен с тем, что удобнее. Несогласен с тем, что прямо сейчас нужно делать именно так. Дело в том, что у нас нет стандартного heap аллокатора, способного эффективно выделять небольшие куски памяти. В результате, под каждый элемент, неважно, насколько он мал, будет выделяться минимум 4 КБайта, что не есть хорошо. Писать аллокатор я сам не хочу, только если кто-то возьмётся.
  4. От системы RTTI никуда уходить не хочется, потому как в будущем планируется сделать возможным создание интерфейсов по текстовому описанию. Что касается widget_is_kind_of, рано или поздно оно в любом случае понадобится.
    Насчёт переноса arrange_widgets в widget_t - нужно подумать. В GTK, например, практически все виджеты наследуются от "контейнера", который, в свою очередь может содержать несколько дочерних виджетов. Даже кнопка. При этом, чтобы сделать кнопку с иконкой, достаточно добавить в кнопку горизонтальный лэйаут, а в него - иконку (виджет, отображающий картинку) и лэйбл (виджет, отображающий текст). По умолчанию же у кнопки один дочерний элемент - лэйбл.
  5. Никогда не подозревал, но сейчас посмотрел на макрос и да, такое возможно. Спасибо за наводку.

_________________
in code we trust


Top
   
PostPosted: Sun Jun 07, 2009 12:31 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
По п.3

а) что еще нет - согласен. Но, рано или поздно его придется писать. Если уж слишком долго его никто писать не будет, значит я напишу.
И опять же, это хорошо разделяемые задачи: заменил модули, и все будет продолжать работать, просто экономнее.

б) мне показалось, что Вы перепутали: это в моем случае динамических блоков меньше :!:
Динамические объекты в Вашем случае: виджет-родитель + массив в него входящий + N * виджеты-детишки, на которые указывают элементы массива
В предложенном мной варианте: виджет-родитель + N * виджеты-детишки, связанные в цепочку, начало которой находится в родителе.
Связи не стоят "ничего", это не динамические объекты, это просто поля-указатели в виджете.
Собственно, как раз "рациональность" в моем понимании и заключалась в этом "меньше". Меньше - это рацональнее при любом алокаторе, имхо.


По п.4
Может и понадобится, спорить сильно не буду... :) Тут правильней оставлять таковую возможность, но не использовать ее без необходимости. Чтобы на заключительном этапе, принятие решения оставить/выкинуть - не вызывало напряжения. ИМХО, конечно.

Вот только мой опыт программирования (создания элементов) под KOL (там автор принципиально отказался от RTTI, а к наличию такового в Дельфях относится крайне скептично) говорит про то, что вполне без этого можно обойтись.
Собственно, понадобилось мне это только один раз.
Там, если делаешь элементы-оболочки над стандартно-виндячими контролами, иногда приходится "вешать аттачи" на родителя. По той причине, что этот "стандартный" - имеет глупую привычку сообщать о изменении своего состояния нотификациями именно родителю.
Конкретно, это были элементы TrackBar и ScrollBar, которые сыпали одинаковыми нотификациями WM_HSCROLL, WM_VSCROLL
Родитель имеет два аттача (каждый класс повесил по одному), каждый из которых должен понять (если поймет неправильно - кердык будет), можно ли приводить к "своему классу" полученный хэндл детишки.

И что характерно - ну не грозит нам такой вариант, если мы не будем специально создавать себе проблемы (слать нотификации родителю, чтобы потом вернуть их назад)

============================================================
Нет, такие вещи уже надо обсуждать в более высоком по абстракции топике....
mike.dld, ну я жду создания Вами "концептуального" топика. Мне это очень интересно, готов высыпать сразу несколько вопросов "функционирования либы", которые мне не очень понятны в разрешении. В смысле - приходящие сразу в голову решения не кажутся рациональными.
А проблем со спешкой - никаких :)


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 14 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited