Лэйауты в Колибри

Assembler programming questions
  • эх, а я (в программе, которая не увидела и не увидит свет) сам писал обработку изменения размеров окна).. Так что весчь нужная
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Правильной дорогой идем! Когда то я далал поделку, там небыло понятия лэйаут но вводился widget, в общем нужна какая то основа-абстракция.
  • mike.dld
    Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно).
    Все замечательно, даже наверное невзъебенно круто (разве что я по причине своего отсталого развития оценить не в состоянии), но меня мучает вопрос: Три года хватит?
    Нет это не стеб, но уже какое начинание мегакрутое, а потом все тухнет и помирает - а между тем BOXLIB уже работает. Да оно не невзъебенно круто как все другие мегапроекты, но тем не менее - работает. И репу особо чесать над тем как использовать не нужно - берешь и подключаешь и все!

    З.Ы. Если я выразился грубо, то ниче не поделаешь - надоело смотреть как мы постоянно тратим усилия на реализацию однотипных вещей в параллельных вселенных. Никакой кооперации, мде...
  • Mario
    Три года, я думаю, хватит. Возможно, хватит и меньше, но что уж мелочиться (зная наши темпы)...
    in code we trust
  • Немного более приближенный к реалиям вариант. Добавил vbox_layout, в результате стало возможным реализовать практически любой интерфейс.
    Attachments
    layout2.7z (7.64 KiB)
    Layout sample (v2)
    Downloaded 480 times
    in code we trust
  • Эта программа что-то наподобие окна с фреймами?
  • это вроде как для построения интерфейса приложения как в GTK или Java.
  • mike.dld wrote:Это то, как я представляю себе начало более-менее правильной библиотеки GUI (точнее, не совсем начало, но одна из основ, без которой писать контролы - смешно). Жду-с комментариев товарищей гуи-строителей
    Ну, в общем-то, все понятно. За исключением назначения поля layout_t.sizing

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

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

    Плюс сразу хотелось бы узнать, имел ли ты дело с лэйаутами ранее (например, при использовании других библиотек), то есть, применял ли ты их на практике.
    in code we trust
  • 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 позволяет наследовать структуры. Примерно так:

    Code: Select all

    struct layout_t container_t
      sizings   ptr_array_t
      sizing    dd ? ; кто такой, почему не знаю...
      spacing   dd ?
    ends
    тогда не пришлось бы приводить один указатель к разным классам

    Code: Select all

            mov     esi, [ebx + layout_t.children] ; было container_t
            mov     edi, [ebx + layout_t.sizings]
    Приведение к разным - напрягает. Особенно по-началу, когда иерархия классов в голове еще не твердо сидит.


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

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

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


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

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

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

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

    Users browsing this forum: No registered users and 0 guests