эх, а я (в программе, которая не увидела и не увидит свет) сам писал обработку изменения размеров окна).. Так что весчь нужная

Правильной дорогой идем! Когда то я далал поделку, там небыло понятия лэйаут но вводился widget, в общем нужна какая то основа-абстракция.

mike.dld

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

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

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

Mario
Три года, я думаю, хватит. Возможно, хватит и меньше, но что уж мелочиться (зная наши темпы)...

Немного более приближенный к реалиям вариант. Добавил vbox_layout, в результате стало возможным реализовать практически любой интерфейс.

Эта программа что-то наподобие окна с фреймами?

это вроде как для построения интерфейса приложения как в GTK или Java.

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

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

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

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

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

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

1) Ну сделайте ветку, интересно будет. Вы изложите схему, которая Вам кажется более естественной, ну а я - которую мне.
Может потом и симбиоз получится, превосходящий все сделанное до сих пор
Как минимум, понимать идеи друг друга - это есть хорошо

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

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

Нижеизложенное является не более, чем соображениями из серии: "я бы делал примерно так".
И ни в коем случае не фиксируют "некие баги" - их просто нет. А "соображения" - не меняют исходной функциональности.


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 позволяет наследовать структуры. Примерно так: тогда не пришлось бы приводить один указатель к разным классам Приведение к разным - напрягает. Особенно по-началу, когда иерархия классов в голове еще не твердо сидит.


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

Извини, что поздновато.

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

По п.3

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

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


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

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

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

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