Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вт ноя 21, 2017 1:14 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 14 сообщений ] 
Автор Сообщение
 Заголовок сообщения: Лэйауты в Колибри
СообщениеДобавлено: Ср май 27, 2009 3:01 am 
Не в сети
Site Founder
Аватара пользователя

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

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

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


Вложения:
Комментарий к файлу: Layouts sample
layout.7z [7.36 КБ]
229 скачиваний

_________________
in code we trust
Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Ср май 27, 2009 8:18 am 
Не в сети
Аватара пользователя

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

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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Ср май 27, 2009 8:45 am 
Не в сети
Kernel Developer
Аватара пользователя

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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Ср май 27, 2009 9:19 am 
mike.dld
Цитата:
Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно).

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

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


Вернуться к началу
   
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Ср май 27, 2009 11:34 am 
Не в сети
Site Founder
Аватара пользователя

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

_________________
in code we trust


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Чт май 28, 2009 8:30 pm 
Не в сети
Site Founder
Аватара пользователя

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


Вложения:
Комментарий к файлу: Layout sample (v2)
layout2.7z [7.64 КБ]
196 скачиваний

_________________
in code we trust
Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Чт май 28, 2009 10:42 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пн окт 27, 2008 10:10 pm
Сообщения: 750
Эта программа что-то наподобие окна с фреймами?


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Пт май 29, 2009 6:20 am 
Не в сети
Mentor
Аватара пользователя

Зарегистрирован: Вт янв 15, 2008 11:27 am
Сообщения: 750
это вроде как для построения интерфейса приложения как в GTK или Java.


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Ср июн 03, 2009 2:46 pm 
Не в сети

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

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Чт июн 04, 2009 1:35 am 
Не в сети
Site Founder
Аватара пользователя

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

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

_________________
in code we trust


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Чт июн 04, 2009 7:57 am 
Не в сети

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

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

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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Чт июн 04, 2009 10:14 pm 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 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 позволяет наследовать структуры. Примерно так:
Код:
struct layout_t container_t
  sizings   ptr_array_t
  sizing    dd ? ; кто такой, почему не знаю...
  spacing   dd ?
ends
тогда не пришлось бы приводить один указатель к разным классам
Код:
        mov     esi, [ebx + layout_t.children] ; было container_t
        mov     edi, [ebx + layout_t.sizings]
Приведение к разным - напрягает. Особенно по-началу, когда иерархия классов в голове еще не твердо сидит.


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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Вс июн 07, 2009 9:35 am 
Не в сети
Site Founder
Аватара пользователя

Зарегистрирован: Вс авг 08, 2004 8:55 am
Сообщения: 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


Вернуться к началу
 Заголовок сообщения: Re: Лэйауты в Колибри
СообщениеДобавлено: Вс июн 07, 2009 12:31 pm 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 180
По п.3

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

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


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

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

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

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 14 сообщений ] 

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB