Embedded GUI, Что поизучать? Опции

[haker_fox]

Добрый день, коллеги!

Посоветуйте, пожалуйста, что можно почитать по принципу создания, проектирования GUI?

Возник соблазн написать что-то свое. На Си++.

Требования к интерфейсу: работа на ARM7+, где-то (с усечениями) на AVR8, разрешение от 128x64 до 1024x768, от монохрома до 8-8-8. Как-то так. Высокая сложность не требуется, хотя я расчитываю, что с Си++ сложность нарастить будет не сложно)))

Знаю, что есть готовые системы. Но хочу поупражнятся сам.

Спасибо!

[Lotor]

Тоже для общего развития хотелось бы почитать какую-нибудь литературу по организации собственного gui на ООП. Наверняка до винды людей волновал этот вопрос и была литература соответствующая. Самое лучшее, что нагуглилось - IMGUI. Может кто из форумчан знает книги по теме?

PS: я в курсе, что самое правильное - взять готовую отлаженную библиотеку.

[haker_fox]

PS: я в курсе, что самое правильное - взять готовую отлаженную библиотеку.

Ну для кого же правильное? Вот для нас с Вами похоже уже не совсем правильное.

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

[dxp]

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

Готовой теории не найдёте, поэтому не тратьте время на это. Начните делать что-то сами - только в процессе делания и придёт понимание и осознание. Посмотреть, как сделано в других системах - полезно. Но именно посмотреть, как сделано то или иное. GUI в каждом случае индивидуален. Тот, что идёт на РС, обычно плохо подходит для embedded систем. Поэтому целиком его оттуда заимствовать достаточно плохая идея. Если взять какой-то готовый типа uCGUI, то придётся оставаться в рамках его идеологии. Не всегда она может хорошо подойти для вашего устройства.

Разработать GUI "по месту" не такая сложная задача (много сложнее разработать универсальный GUI, чтобы он хорошо подходил под разные устройства). Начните с самых основ. В этом деле есть, так сказать, "три кита":

1. Обработка/обслуживание ввода. Это обработка сигналов от органов управления - кнопки, энкодеры и т.п.
2. Виджеты и их иерархия. Вся совокупность элементов графического интерфейса, их взаимосвязь и отображение.
3. Вывод. Связь с дисплеем через HAL (набор функций/объектов для управления устройством визуализации и передачи на него видеоинформации).

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

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

Самая база содержит абстрактный класс и базовый класс виджета типа такого:

CODE

namespace gui
{
    //--------------------------------------------------------------------------
    //
    //     Main object types hierarchy
    //
    class TObject
    {
    public:
        virtual void on_message(TBaseMsgWrapper *msg_wrp) = 0;

    };
    //--------------------------------------------------------------------------
    class TWidget : public TObject
    {
    public:
        TWidget() : Pos(), Visible(true), Selected(false) { }
        TWidget(TPoint pos, bool visible = true) : Pos(pos), Visible(visible), Selected(false) { }
        
        virtual void on_message(TBaseMsgWrapper *msg_wrp);
        
        virtual void draw()      { }

        // keys
        virtual void enter()     { }
        virtual void back()      { }
        virtual void help()      { }

        // encoder
        virtual void next()      { }
        virtual void prev()      { }
      
        void   set_pos(const TPoint pos)     { Pos = pos;  }
        void   set_pos(const int_fast16_t x,
                       const int_fast16_t y) { Pos.x = x; Pos.y = y;  }

        TPoint pos    () const               { return Pos; }
    
        void set_visible(bool x) { Visible = x;    }
        bool visible    () const { return Visible; }
          
        void set_selected(bool x) { Selected = x;    }
        bool selected() const     { return Selected; }
        
    protected:
        TPoint Pos;
        bool   Visible;
        bool   Selected;
    };

    ... //
}

Очень важная фукнция on_message() - именно она является каналом передачи информации от органов управления и других частей программы (например, приходит сообщение по UART'у с требованием что-то сделать). Поскольку у каждого объекта GUI есть такая фукнция, то он может реагировать соответствующим образом. Подробно тут останавливаться на реализации этой функции не буду, это можно обсудить отдельно, если есть интерес.

Далее, класс TWidget являет собой базу для любого виджета в данном системе - меню, пункты меню, скроллбары, диалоговые окна сообщений и т.п.. Он содержит минимальный набор данных - позиция, и два свойства: видимый или нет и выделенный или нет. Понятно, что в другой системе свойства могут быть другими - вместо этих будут что-то своё. Ну, и интерфейс для работы этим представлением. TPoint - это простая структура, реализующая функционал объекта "точка на экране", содержащая координаты и функции для работы с ними, там всё тривиально. Набор виртуальных функций важен. Функция draw() нужна всегда - это отрисовка виджета, она всегда индивидуальна. Остальные функции завязаны на целевое устройство. В данном случае у нас есть несколько кнопок и энкодер. Реакция каждого виджета на органы управления тоже, понятное дело, индивидуальна, поэтому эти функции у каждого виджета свои.

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

Обработка ввода и управление GUI выглядит в данном примере выглядит примерно так. Есть главный цикл GUI, в котором и осуществляется вся динамика этого процесса:

CODE

    ... //
    for(;;)
    {
        Input.handle();
        timer();
        sleep(40);
        
    }

В данном примере цикл работы движка GUI составляет 40 мс + время работы собственно движка. Input - это объект, который отвечает за обработку органов управления (кнопки, энкодер), timer - функция, которая генерирует сообщения о временных отметках - некоторые виджеты требуют таких сообщений, чтобы отрабатывать свой функционал - например, часы или таймер, которые отображают изменяющееся время на экране. Сюда можно добавить ещё подобных элементов, чтобы расширить функциональность - например, как уже говорилось выше, передавать информацию, поступающую по последовательному порту от другого устройства, данные от АЦП и т.д.

Передача собственно информации осуществляется с помощью передачи сообщения объекту под фокусом. Выше есть объявление:

CODE

TWidget                      *Focus;
stack<gui::TWidget *, 8>      FocusHistory;

Здесь есть указатель на виджет и групповой объект (на 8 элементов), для хранения фокусов.

Передача информации осуществляется следующим образом. Когда, например, сигналы от органов управления обработаны и есть информация о том, что та или иная кнопка нажата/отжата/удерживается или был осуществлён поворот энкодера, формируется тело сообщения и посылается объекту под фокусом:

CODE

    ... //  опрос кнопок и формирование результата опроса: KeyPattern описывает какие кнопки были нажаты,
    ... //   KeyEventKind - тип события - нажато/отпущено/удерживается

    if(  ( KeyPattern == ENTER && KeyEventKind == TKeyEvent::PRESSED ) ) // кнопка Enter нажата
    {
        TInputMessage Msg = gui::imENTER;             // тело сообщения, в данном случае простой объект перечислимого типа
        send_message<gui::TInputMessage>(&Msg, Focus); // передача сообщения текущему виджету
    }
    
    if( KeyPattern == BACK && KeyEventKind == TKeyEvent::PRESSED )
    {
        TInputMessage Msg = gui::imBACK;
        send_message<gui::TInputMessage>(&Msg, Focus);
    }
    ... //

Аналогично обрабатываются остальные органы управления и передаются соответствующие сообщения. Приём сообщения выглядит так:

CODE

void gui::TWidget::on_message(TBaseMsgWrapper *msg_wrp)
{
    gui::TInputMessage *msg = check_msg<gui::TInputMessage>(msg_wrp);   // проверяется соответствие типа сообщения, 0 возвращает, если не соответствует
    
    if(msg)
    {
        switch(*msg)
        {
        case gui::imENTER : enter(); break;
        case gui::imBACK  : back();  break;
        case gui::imHELP  : help();  break;
        case gui::imNEXT  : next();  break;
        case gui::imPREV  : prev();  break;
        default           : print("error: unknown message");
        }
    }
}

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

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

Подобный принцип используется во многих GUI движках, в частности в Qt очень похожая схема с объектами событий (QEvent).

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

Если что-то не ясно, готов ответить на любые вопросы.

P.S. Хотел написать три строчки, пару общих советов, а получилось...

[haker_fox]

Подобный принцип используется во многих GUI движках, в частности в Qt очень похожая схема с объектами событий (QEvent).

Если что-то не ясно, готов ответить на любые вопросы.

Посольку работаю в контектсе scmRTOS, очень удобным кажется передавать такие события через объект OS::channel. Это правильно?

[dxp]

Посольку работаю в контектсе scmRTOS, очень удобным кажется передавать такие события через объект OS::channel. Это правильно?

Если это вопрос о передаче информации объектам GUI, то нет, там используется иной механизм (могу рассказать подбробнее). А OS::channel можно использовать для передчи сообщений в главный цикл GUI из других процессов и обработчиков прерываний.

[haker_fox]

Если это вопрос о передаче информации объектам GUI, то нет, там используется иной механизм (могу рассказать подбробнее). А OS::channel можно использовать для передчи сообщений в главный цикл GUI из других процессов и обработчиков прерываний.

Если можно, расскажите, пожалуйста, подробнее. В чем отличие. Для меня это все пока одинаково выглядит.

На данном этапе развития ГУИ я планирую сделать так.

Завести структуру сообщения в виде

CODE

enum FMessageType
{
    FMsgFromKbd,
    FMsgFromTouch,
    FMsgFromADC
    // и т.д. по мере необходимости
};

struct FMessage
{
    FMessageType msg; // тип сообщения (от кого пришло)
    // Здесь надо подумать, как унифицировать данные от клавиатуры и других объектов, т.к. типы передаваемых данных разные

}

Ну и отправлять сообщения из любого потока ОС, которое что-то хочет отправить ГУИ. А последняя пусть сама разбиарается, что с этим сообщением делать (игнорировать, построить очередную точку на диаграмме, "нажать" кнопку...)...

[AHTOXA]

Подумайте сразу о параметрах сообщения. Ну, типа координат нажатия на экран, кода нажатой клавиши, значения АЦП...

[haker_fox]

Подумайте сразу о параметрах сообщения. Ну, типа координат нажатия на экран, кода нажатой клавиши, значения АЦП...

Совершенно верно! Поскольку очередь сообщений OS::channel предназначена для передачи данных конкретного типа (а это ее преимущество, чтобы не плодить сущности с указателями void*), необходимо как-то унифицировать тип сообщения. Пока думаю...