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 из других процессов и обработчиков прерываний.

[mdmitry]

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

Весьма интересно узнать, какие идеи заложены в Вашем решении.

[dxp]

Весьма интересно узнать, какие идеи заложены в Вашем решении.

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

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

Реализация механизма следующая. Сразу приведу весь код, ниже будет дано пояснение:

CODE

//------------------------------------------------------------------------------
inline uint16_t generate_id() { static uint16_t id; return ++id; }

class TBaseMsgWrapper
{
public:
    virtual uint16_t get_id() = 0;
};

template<typename T> class msg_wrapper : public TBaseMsgWrapper
{
public:
    msg_wrapper(T *msg) : body(msg), TBaseMsgWrapper() { }
    
    static  uint16_t get_class_id() { static const uint16_t id = generate_id(); return id; }
    virtual uint16_t get_id()       { return get_class_id(); }
    
    T *get_msg() const { return body; }
    
private:
    T *body;
};

template<typename T> T *check_msg(TBaseMsgWrapper *msg_wrp)
{
    if( msg_wrp->get_id() == msg_wrapper<T>::get_class_id() )
    {
        return (static_cast<msg_wrapper<T> *>(msg_wrp))->get_msg();
    }
    else
    {    
        return 0;
    }
}

template<typename T> bool send_message(T *msg, gui::TObject *dst)
{
    msg_wrapper<T> msg_wrp(msg);
    dst->on_message(&msg_wrp);
    
    return true;
}
//------------------------------------------------------------------------------

Ключевыми частями являются функция generate_id() и шаблон msg_wrapper. Функция generate_id() при каждом вызове возвращает целое с новым значением (увеличенным на 1 в данном случае), и служит, как ясно из названия, для генерации уникальных идентификаторов. Внутри шаблона msg_wrapper есть механизм получения и предъявления уникального (для каждого типа) идентификатора. Реализован с помощью пары функций get_class_id() и get_id().

Функция get_class_id(), собственно, и производит получение уникального идентификатора и его хранение. Сделано это на основе свойства статических локальных переменных инициализироваться "по месту":

CODE

static  uint16_t get_class_id() { static const uint16_t id = generate_id(); return id; }

При первом входе в функцию, внутренняя статическая константа id получает значение, которое затем возвращается. В дальнейшем при вызове этой функции только возвращается это единыжды полученное значение. Таким образом, каждый тип сообщения, передаваемый через msg_wrapper, получает автоматом свой уникальный целочисленный идентификатор.

Функция get_id() является интерфейсом для доступа к этому идентификатору. Поскольку сообщения могут передаваться произвольными, нельзя при передаче указывать конкретный тип. Вместо этого передаётся указатель на базовый класс всех типов сообщений, и получение уникального идентификатора производится через виртуальную функцию, чтобы получить для каждого конкретного типа именно своё значение.

Ну, далее пара функций - передачи и приёма. Передача:

CODE

template<typename T> bool send_message(T *msg, gui::TObject *dst)
{
    msg_wrapper<T> msg_wrp(msg);
    dst->on_message(&msg_wrp);
    
    return true;
}

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

CODE

    .... //
    if( ... )
    {
        TMessageBody Msg = ...;
        send_message<TMessageBody>(&Msg, Focus);
    }
    ... //

Приём выглядит так (пример приводился выше, повторяю для связности изложения):

CODE

void gui::TWidget::on_message(TBaseMsgWrapper *msg_wrp)
{
    gui::TInputMessage *msg = check_msg<gui::TInputMessage>(msg_wrp);
    
    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");
        }
    }
}

Здесь на входе проверяется соответствие типа сообщения ожидаемому; если соответствует, то дальше производится обработка тела сообщения. Соответствие выражается в значении возвращаемого указателя функции check_msg(). Если сообщение соответствует ожидаемому, то возвращается указатель на тело сообщения, если не соответствует, то возвращается ноль:

CODE

template<typename T> T *check_msg(TBaseMsgWrapper *msg_wrp)
{
    if( msg_wrp->get_id() == msg_wrapper<T>::get_class_id() )
    {
        return (static_cast<msg_wrapper<T> *>(msg_wrp))->get_msg();
    }
    else
    {    
        return 0;
    }
}

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

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

CODE

void gui::TModeControl::on_message(TBaseMsgWrapper *msg_wrp)
{
    gui::TTimeIntervals *TimeMsg = check_msg<gui::TTimeIntervals>(msg_wrp);   // сообщения о временнЫх метках
    gui::TModeContolMsg *MCMsg   = check_msg<gui::TModeContolMsg>(msg_wrp);   // "проприетарные" сообщения для данного виджета

    if(TimeMsg)
    {
        switch(*TimeMsg)
        {
              ... //
        }
    }
    else if(MCMsg)
    {
        switch(*MCMsg)
        {
        case gui::mcmCONTACT_LOST:
            {
                 ... //
            }
            break;

        case gui::mcmELECTRODE_OFF:
            {
                ... //
                print("Electrode is off\r\n");
            }
        ... //
        default:
            print("error: unknown mode control message\r\n");
        }
        
    }
    else
    {
        TWidget::on_message(msg_wrp);    // переслать необработанные сообщения дальше
    }
}
//------------------------------------------------------------------------------

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

Напоследок замечание (это больше для haker_fox). Не следует путать сообщения, передаваемые по вышеописанной схеме, с сообщениями, передаваемыми через средства межпроцессного взаимодействия (типа OS::channel), механизмы реализации и назначение совершенно разные. Вариант send_message/check_msg - это передача сообщения в главном цикле GUI от источников к виджетам. Передача эта синхронная - в момент передачи сообщение и принимается, и обрабатывается - это всё одна и та же цепочка вызовов функций. А передача сообщений через OS::message или OS::channel - это передача асинхронная, потокобезопасная и через промежуточный объект, в котором хранится тело сообщения. Передавать через send_message() из другого процесса можно, но это небезопасно с точки зрения межпроцессного взаимодействия.

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

Вообще, сам способ генерации и проверки уникальных идентификаторов типов, описанный выше, достаточно универсален и может применяться везде, где требуется подобная проверка на рантайме. В некоторых случаях может вполне успешно заменять RTTI. Прикручивал этот механизм к объектам QEvent, легло вообще отлично благодаря сходности базы объектов событий пакета Qt. Там им только не хватало автоматической генерации идентификаторов и проверки, а сами типы событий там идентифицируются тоже на основе целочисленных переменных.

[_pv]

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

возможно я не до конца осознал всю радость от знания типа объёктов, но чем хуже использовать просто int в качестве сообщений, у самого базового класса Widget сделать виртуальный handle(int event), за который и дергать потом все виджеты подряд.
а уже в этом обработчике доставать откуда надо необходимые данные, если нужно:
int handle(int event){
switch (event){
case EVENT_KEYBOARD: int key = get_key(); ...
...
}
так, насколько я понимаю, в FLTK сделано.

[dxp]

возможно я не до конца осознал всю радость от знания типа объёктов, но чем хуже использовать просто int в качестве сообщений, у самого базового класса Widget сделать виртуальный handle(int event), за который и дергать потом все виджеты подряд.
а уже в этом обработчике доставать откуда надо необходимые данные, если нужно:
int handle(int event){
switch (event){
case EVENT_KEYBOARD: int key = get_key(); ...
...
}
так, насколько я понимаю, в FLTK сделано.

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

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

[mdmitry]

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

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

[dxp]

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

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

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

[mdmitry]

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

Спасибо, dxp.
Поясните, пожалуйста, как Вы делаете именно связь между элементами GUI для управления. По нажатию кнопки выбран элемент из списка №1 (режимы работы). Есть связанный со списком №1 список №2 (специфические (уникальные) для данного режима подрежимы). Как в этом случае делается переключение на нужный список №2.
Как-то так:

Код

режим1
    подрежим11
    подрежим12
    подрежим13
режим2
    подрежим21
    подрежим22
режим3
    подрежим31
    подрежим32
    подрежим33

[dxp]

Поясните, пожалуйста, как Вы делаете именно связь между элементами GUI для управления. По нажатию кнопки выбран элемент из списка №1 (режимы работы). Есть связанный со списком №1 список №2 (специфические (уникальные) для данного режима подрежимы). Как в этом случае делается переключение на нужный список №2.

Ну, т.е. что-то вроде системы меню? Это несколько другая тема, чем передача сообщений. Тут тоже может быть несколько реализаций. Я делаю связь через промежуточный объект Target. При создании пункта меню ему присваивается объект Target, который представляет собой простой объект из иерархии таржетов. Все их объединяет метод (виртуальная функция) exec(), которая и вызывается внутри метода объекта пункта меню, отвечающего за реакцию на нажатие соответсвующей кнопки. Схема действий проста: внутри переключается фокус и вызывается перерисовка, а также выполняются все сопутствующие действия.

Если приводить аналогию из С, то этот способ похож на связть через указатель на функцию, которая и выполняет действия. Тут просто эта функция "завёрнута" в объект Target, что делает использование более безопасным и удобным (можно хранить внутри этого объекта какие-то служебные переменные). Использование промежуточных объектов позволяет гибко настроить целевые действия при активации виджета. Если не очень понятно описано, скажите, пример приведу (сейчас его нет под рукой).

AlexandrY, именно так и делается, см самый первый мой пост в этой теме - главный цикл GUI. Все сообщения посылаются из него с его темпом.

[AlexandrY]

AlexandrY, именно так и делается, см самый первый мой пост в этой теме - главный цикл GUI. Все сообщения посылаются из него с его темпом.

Цикл в первом посте выглядит совсем плохо.
Получается искусственно созданный задержкой затор.
В это время в очереди может накопиться куча сообщений которые GUI должно быть выполнить все одним рывком.
Это как минимум будет выглядеть некрасиво на экране.

[dxp]

Цикл в первом посте выглядит совсем плохо.
Получается искусственно созданный задержкой затор.
В это время в очереди может накопиться куча сообщений которые GUI должно быть выполнить все одним рывком.
Это как минимум будет выглядеть некрасиво на экране.

Да, давайте обсудим недостатки простых примеров, приведённых для упрощения понимания. Ясно, что ничего не мешает этот цикл сделать так, как хочется - например, создать очередь сообщений от других процессов. К тому же, даже в том примере цикл составляет 40 мс, этого вполне достаточно для комфортной реакции GUI на события - врядли вы успеете заметить торможение при обновлении информации, если, конечно, не рубитесь в Unreal Tournament.

[AlexandrY]

Да, давайте обсудим недостатки простых примеров, приведённых для упрощения понимания.
...цикл составляет 40 мс, этого вполне достаточно для комфортной реакции GUI на события - врядли вы успеете заметить торможение при обновлении информации...

Я думаю задержка там концептуально поставлена, а не для простоты.
Она именно дает GUI передохнуть.
Скорее всего жертвуется событиями от клиентских для GUI задач.

Для маленьких монохромных экранов 40 мс скорее всего будет незаметно.
Но для больших цветных панелей с тачскрином где весь цикл прорисовки занимает больше 40 мс последствия задержки сразу будут заметны.

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

Вообщем преимущества продемонстрированной реализации весьма спорны, либо она уж очень упрощена

[dxp]

Я думаю задержка там концептуально поставлена, а не для простоты.
Она именно дает GUI передохнуть.

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

Скорее всего жертвуется событиями от клиентских для GUI задач.

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

Для маленьких монохромных экранов 40 мс скорее всего будет незаметно.
Но для больших цветных панелей с тачскрином где весь цикл прорисовки занимает больше 40 мс последствия задержки сразу будут заметны.

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

Интересно, упор делается на такой мелочи как автоматическая генерации идентификаторов сообщений,

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

хотя на самом деле главный цикл для большого количества сообщений не приспособлен.

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

Это не считая того, что автоматически сгенерированные идентификаторы усложняют отладку и ведение лога.

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

Вообщем преимущества продемонстрированной реализации весьма спорны, либо она уж очень упрощена

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