[Devel] Идея привязки событий к виджетам

[Evgeny Sinelnikov]

29 сентября 2010 г. 21:36 пользователь Pavel Vaynerman
<vpashka на gmail.com> написал:
>> С замечанием согласен, но сейчас про все это "знает" MainWindow.
>
>> Не думаю, что текущее решение более "инкапсулировано".
>
> Я и не писал, что мне нравиться текущее решение..
>

А чем оно вам не нравится? Это в стиле текущей архитектуры uniwidgets,
на которую ссылается Паша.

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

Вот, в общем-то, и все виджеты.

Какие возникают с ними проблемы? А вот такие:
- Как задать одинаковую логику и набор приоритетов для заданной
задачи, например, автомата?
Написать новый виджет. Или задавать один и тот же набор обработчиков в
MainWindow.
- Как сделать группу объектов, которые будут реагировать на события,
как один объект, например, на реакцию меню?
Вариант1: Внести виджеты в контейнер и обрабатывать события от него.
Тогда нужно пробрасывать события в виджеты на контейнере, если это
EventBox или регистрировать одинаковые обработчики для всех виджетов,
включая контейнер, если это HBox;
Вариант2: Написать новый виджет.

Думаю, что Вариант1+HBox - самый простой вариант. Проблемы с меню
начинаются, если пытаться написать свой виджет.



Теперь про меню. Меню это внешний, по отношению к виджетам объект,
поэтому не нужно пытаться засунуть обработчик событий меню в
какие-либо виджеты. Да, меню можно сделать более удачным образом и
вынести в отдельный файл. Можно даже отдельный класс написать.

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

Идея сделать список дачтиков группы (Напряжение, Частота, Ток,
Мощность) в одном меню - моя. Мне кажется, что неудобно пытаться
попасть в отдельный датчик когда мы визуально видим группу датчиков (у
нас по четыре, где-то три, датчика), кроме того поле группы тоже
должно выдавать какой-то список. Поэтому я предложил показывать их все
в меню по правой кнопке. Появилась задача передать указатели на
соотвествующие виджеты в меню.

И новые объекты меню, и новые классы для меню появились вслед за этим.

При этом никто ещё не утвердил этот вариант. Хочу уточнить как я это себе вижу:
- Правой кнопкой по объекту из группы датчиков мы получаем список из
таких пунктом меню как:
  - "Список параметров"
  - "Печать"
  - "Напряжение на новый график" или "График напряжения" или....
  - "Ток на новый график" или "График тока" или....
  - "Частота на новый график" или "График частоты" или....
  - "Мощность на новый график" или "График мощности" или....
- Drag&Drop левой клавишей по заданному аналоговому виджету, позволяет
бросить его на сущестующий график
- Двойной щелчок на заданном аналоговом виджете открывает его в новом
графике, как из меню по правой клавише.

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

У нас восемь или более групп объектов с аналоговыми датчиками. Красиво
сделать вызвать в MainWindow восемь раз некий метод регистрации
обработчиков вместо более 8x4=32 обработчиков. Но стоит ли оно того
сейчас?

Я предложил сделать два метода обработки. Первый получает обычный
GroupObject, по которому мы выясняем список датчиков, которые
относятся к объекту. Второй, кроме GroupObject, получает список
(контейнер или обычный массив) виджетов, которые нужно дополнительно
указать в меню.

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

Но если делать так, то на каком этапе регистрируются обработчики
отдельных виджетов для Drag&Drop и для двойного щелчка?

Всё равно, в главном окне придётся получать это список и
регистрировать соответсвующие обработчики.
Вносить же эти обработчики в сами виджеты, совершенно неправильно.



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

У нас та же ситуация. Число объектов можно уменьшить, но, если
обработчики должны быть у подобъектов, то мы всего лишь можешь
получить интерфейс для регистрации обработчиков этих подобъектов.
Число регистрируемых обработчиков от этого не уменьшиться.

Ну, разве что, если у подобъектов будут одни и те же обработчики,
тогда цикл по проходу по ним можно внести в интерфейс самих объектов.
Но так ли это существенно?



-- 
Sin (Sinelnikov Evgeny)