Спасибо, dxp.
Пример был бы интересен.
У меня элементы меню - объекты с соответствующими свойствами. Обработка клавиш - вызов виртуальной функции для элемента. Вопрос как эффективно (красиво) обеспечить управление видом и содержанием элемента меню (ведомого) (или листбокса, едитбокса) в зависимости от состояния другого элемента (ведущего). Мое решение ассоциируется у меня с костылями (некрасиво, неэффективно).

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

Не передохнуть, а просто нет необходимости обновлять информацию на экране чаще.


Какими же это? Мне про это ничего не известно. Расскажите?


Посмотрел, в текущей работе экран 320х240 прорисовывается целиком за 3 мс. Учитывая, что полная перерисовка требуется весьма редко (обновляются только гораздо меньшие фрагменты), то никаких проблем нет. В другом приборе экран 800х600, время обновления не замерял, ни малейших тормозов не наблюдается. С большими экранами и платформа побыстрее.


Мелочи? Покажите, как вы делаете подобные вещи? Как осуществляется доставка сообщений от событий к виджетам?


Настал момент вам показать свой, хороший, правильный вариант главного цикла. Покажите, очень интересно?


С чего это? Обоснуйте?


Ждём правильный вариант.

Вопрос не в необходимой частоте вывода на экран, а в том что каждый внешний (из другой задачи) ивент вы обрабатываете по всей цепочке виджетов заново. Итого куча холостых циклов. Вот и ставите задержку чтоб не перенапрягать GUI холостой работой. А затора избегаете пропуском ивентов. Может очищаете буфер очереди или еще что. Это уж вам виднее. Вы ж свою реализацию не выкладываете.

Про доставку я уже говорил. У Microchip-а просто есть глобальный связный список виджетов. Все идентификаторы событий сведены в одном заголовочном файле. Просто и понятно.
При отладке какой бы релиз библиотеки не взяли каждый определенный числовой идентификатор всегда соответствует одному и тому же событию.
Не надо шерстить все исходники чтобы отыскать все старые и новые типы событий для того чтобы правильно их описать в логе.

Кстати, упор на фокус тоже не очень понятен. Если экран с тачскрином, то зачем вообще иметь такой атрибут как фокус?
Может быть это синоним привязки видджетов ввода к виджетам вывода? Но тогда фокусов должно быть много.

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

Гм, не думал, что скромный вопрос разовъется в жаркую дискусию) Это хорошо!

По-маленьку создаю виджеты. Вроде получается. Основные сложности намечаются в:
1. Перересовке виджетов (весь экран перерисовывать нецелесообразно, надо подсмотреть в какой-нибудь библиотеке красивый алгоритм).
2. Получение данных "в ГУИ" от клавиатуры, АЦП и т.п. Здесь уже алгоритм предложен, но нужно все еще раз обдумать и "вживит" в свою реализацию.

По какой цепочке? Цепочке, состоящий из чего? Покажите? Объясните, с чего вы сделали такой вывод?

1.

2.

3.


Аж целых три сильных заявления! И ни одно не имеет даже намёка на обоснование. Это ваши фантазии, ничего этого там нет. Может, перестанете уже фантазировать и попробуете разобраться в том коде, который я привёл (если что-то не понятно, готов ответить на вопросы). А если не желаете, считаете это ниже своего достоинства, то тогда прошу перестать писать комментарии, содержание которых не имеет к действительности никакого отношения, и демонстрирующие непонимание комментируемого.


Уже практически всё выложил. А вы и не заметили.


Понятно. Самый примитивный вариант. На С по-другому особо и не разбежишься. При добавлении и/или удалении события придётся ручками следить за соответствием идентификаторов. Закат Солнца вручную. Именно то, от чего всегда хотелось уйти - пусть машина этим занимается, она не ошибается. Другое дело, что используемый инструментарий не позволяет.


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


Если. А если нет? Показан простой пример. Тем не менее, прекрасно работающий. Будет тачскрин, будет чуть иная реализация.


Сколько угодно. В данном примере один. Выше описывал вариант, когда может быть несколько. Ничего ничему не противоречит, не мешает, расширяется сколько угодно в любую сторону без переделки "каркаса".


Во-первых, я и не просил ваши исходники. Вы цикл критиковали, я попросил ваш вариант цикла, лишённого недостатков критикуемого. Принцип, псевдокод - компилировать его никто не будет.

Во-вторых, я-то свой код уже практически выложил. Иерархия виджетов, схема передачи сообщений им. Вам что, ещё реализации методов draw() каждого виджета показать? Весь проект GUI представлен (кроме уровня вывода на устройство визуализации). Те, кто это понял, уже давно дали оценку. Кто ещё не вник, но хочет разобраться, пытаются это сделать. Кому это без разницы, те проходят мимо. Вы же, не разобравшись, наводите критику, содержание которой не имеет никакого отношения к действительности - выдуманы какие-то сущности и подвергаются критике.

Да, этот GUI такой маленький, что вы и не заметили, что это практически всё (остальное рюшечки). Да, такой "примитивный", что кода всего на пару экранов. Тем не менее, схема уже обкатана на двух серьёзных приборах и отлично себя зарекомендовала. Результирующего кода, конечно, гораздо больше (несколько тысяч строк), но это реализация функциональности виджетов.


Несколько раз уже всё обсосано. Повторяю ещё раз. Имеет цикл обработки входящих событий, умеет передавать сообщения от событий виджетам, реализует требуемое поведение виджетов. Это основные функции любого GUI. При этом код весьма компактный, очень простой (для человека, свободно читающего на С++), сколько угодно расширяемый по основным функциям.


Во-первых, не масштабируемость, а расширяемость. Расширяемость нужна всегда.

Во-вторых, не автоматическая генерация идентификаторов, а система передачи сообщений с проверкой соответствия. И уж как это сделано внутри - дело пятое. Не туда смотрите, не там акценты расставляете.


* * *


Не очень понял, что именно требуется. Вы имеете в виду вариант, когда, скажем, перемещаем курсор по меню от одного пункта к другому, и при этом где-то рядом отрисовывается подменю, каждый раз другое (у каждого пункта меню своё подменю)? Этот вариант? Или что-то иное? Объясните словами поподробнее, что должно быть на экране, как оно должно реагировать на события?



* * *


Это в большей степени зависит от особенностей аппаратуры визуализации, проще говоря, от контроллера дисплея (хотя не всегда он есть). Например, SSD1963 хорошо приспособлен для заливки прямоугольных фрагментов, но не имеет теневого буфера. Поэтому тут нужно по месту быстро обновлять изменившиеся фрагменты. В другом приборе у меня был теневой буфер в SDRAM и возможность быстро залить этот буфер в рабочий буфер, с которого идёт рефреш. Тут без разницы, сколько информации на экране вы меняете - всё равно перезаливается весь буфер, но происходит это очень быстро (800х600 за 2.4 мс) в паузах между рефрешем очередного кадра (там VESA). Поэтому не ищите универсального решения - в каждом случае свои особенности, плясать тут приходится от особенностей доступной аппаратной части видеовывода.


Для начала возьмите, как есть и сделайте простейший вариант - обработка событий от кнопок парой виджетов. Когда заработает, сразу поймёте, что хорошо, что нет, что нравится, а что не нравится, чего не хватает, а что лишнее. И увидите вариант, который вам подойдёт лучше всего.

Уважаемый AlexandrY, просим, просим! Выложите, хотя бы шкелет


У меня аппаратный котроллер LCD в LPC2478

Спасибо!

dxp, минимум в одной теме на форуме встречал уже Ваши идеи по GUI и передачи сообщений - там они были описаны не так развернуто, но уже тогда я разглядел полезность для себя и успел сохранить, пока тема не захлебнулась в холиваре и самоутверждении некоторых товарищей...

Этот топик ждет такая же участь.

Не приходила ли Вам мысль зафиксировать подобные примеры в документации к scmRTOS в разделе "Примеры использования"?

Так это ведь не про ось, это как бы ортогональные вещи. GUI сам по себе. А способ передачи сообщений - это типа лёгкий аналог dynamic_cast<> (RTTI), не везде полностью заменяет, но во многих случаях вполне. И применяться может почти на любой мелочи в отличие от.

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

В подфоруме по ПЛИС есть тема под названием "Схемотехнические трюки" или как-то так. Там народ делился всякими HDL приёмами. Возможно, что и по программированию имеет смысл создать такую тему и складывать туда интересные посты по программерским приёмам, паттернам. Тему сделать закрытой с доступом только модераторов, чтобы не флудили в ней. Правда, это работа для модераторов.

P.S. Я подумаю над вашим предложением. Возможно, имеет смысл всё-таки написать нормальную статью (когда со свободным временем будет получше).

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

А не надо нам виртуальные окна. Организацию главного цикла и передачу евентов виджетам покажите (обсуждение ведь идёт об этом "одном незначительном аспекте")?

Например:
Есть три листбокса. В первом устанавливается режим устройства (несколько). Во втором в зависимости от установленного режима предлагаются варианты подрежимов (число ращное в зависимости от режима) для выбранного режима. Третий листбокс устанавливает параметры подрежима, число которых (параметров) зависит от выбранного подрежима) . Смена режима должна изменить предлагаемые подрежимы и параметры. Смена подрежима должна изменить список допустимых параметров.
режим->подрежим -> параметр.
Надеюсь прояснил ситуацию

посмотрите на FLTK, легкий и простой, можно посмотреть как некоторые веши сделаны перед тем как свои велосипеды изобретать.
у каждого виджета есть колбэк за который его дергает родитель в определённых случаях. в этом колбэке, который может быть и один зарегистрирован у всех заинтересованных виджетов, меняем переметры у всех остальных в зависимости от значений:
ну и виджеты иерархически огранизованны, и есть базовый класс Group от которого унаследованы окна/составные виджеты/... соответственно они хранят список подопечных виджетов и по приходу сообщения сверху дергают передают его через handle или дергают за callback всех кто снизу.

Спасибо, уже смотрел. Наверно не очень внимательно. А так же глянул на gtkmm и wxWidgets.

Раз уж здесь такая дискуссия, то позволю вбросить ещё вопрос.
Система меню, IMHO, совокупность связанных меджу собой однородных (или почти) объектов. К объектам можно отнести и другие элементы GUI, такие как, листбоксы, эдитбоксы и др. Объект может быть визуализирован, причем на разных экранах (размеры, цвета) визуализация получается разная. Отсюда вопрос: имеет ли смысл делать виджеты, завязанные на графическое представление и дающие необходимый функционал? Альнернатива: объекты хранят информацию, связи и взаимодействия (передча управления друг другу). Графический драйвер обеспечивает необходимую визуализацию. Смена экрана означает только смену драйвера. Идею этого разделения увидел тут

Ага, вроде, понял. Типа, нужно менять и отрисовывать виджеты по цепочке. Модель, как я понимаю, выглядит следующим образом. Есть Список1, в котором некоторое количество пунктов. Каждый пункт имеет связь с другим объектом Список2. Аналогично, каждый пункт у объекта типа Список2 имеет связь с объектом типа Список3. Вопрос в том, как связать пункты и их объекты списков.

Один из вариантов может выглядеть так (я применяю приблизительно такой способ в текущем проекте). Линки между пунктами списков и их целевыми объектами реализовываются через промежуточный объект (TList - тип списка, TListItem - тип элемента списка, все они потомки TWidget):


Все таржеты, в духе идеологии, являются потомками от TTarget, в данном случае у нас пока один тип. Далее, у пункта списка есть привязка к таржету:



Активизация следующего по цепочке списка осуществляется, скажем, по нажатию на кнопку (пусть будет enter), которая вызывает выполнение метода enter() виджета, в случае списка это будет:


Комментарий. Items - групповой объект, который собственно содержит список пунктов. Может быть реализован на основе простого массива, может - на основе std::vector, std::list или какого-либо другого вида контейнера. curr_item() - функция-член Items, возвращает указатель на текущий элемент (пункт списка в данном случае). Реализация хранения группы элементов и интерфейс доступа к ним может быть каким угодно, это не накладывает ограничений на общий принцип.

Если при прохождении по списку нужно отрисовывать цель (для пунктов объекта типа Список1 - это объекты типа Список2), то внутри метода draw() пункта списка вызывать метод draw() цели:



Функция draw_target() вызовет перерисовку списка, который является целью, например, если это был объект типа Список2, то он будет перерисован, при этом его выбранный пункт будет вести себя аналогично - перерисует свой таржет.

Схема с промежуточными объектами-таржетами может показаться громоздкой, но зато она "развязывает" виджет от его цели. Аналогом может служить указатель (или несколько указателей) на функцию, которая выполняет целевые действия. Но реализация через объект получается компактнее, проще - ведь все его методы, выполняющие действия по отношению к таржету, заключены в одном месте, кроме того, объект может кроме функций иметь какие-то служебные данные и вспомогательные функции, чтобы иметь возможность производить какие-то более нетривиальные действия, не привязываясь ни к виджету-владельцу, ни к цели. Это даёт расширяемость.

Итоговое подключение состоит из создания объекта-таржета и передачи указателя на него виджету:



Возможно, сумбурно написано - сложно, не зная тонкостей задачи, написать коротко и точно. Данный пример преследовал цель продемонстрировать принцип. Имена типов и объектов, конкретная реализация функций могут (и должны) быть своими.

Честно говоря, мне самому не доставляет восторга такая схема, несколько громоздко, на мой взгляд. Но она работает и нет проблем с "завязками". Если у кого-то есть на примете более лёгкий и логичный вариант, но в то же время гибкий и удобный, я удовольствием бы ознакомился.


А кто отвечает за собственно внешний вид виджетов? Их размеры, цвета и прочее.