QT: Использование конечного автомата для взаимодействия с пользовательским интерфейсом?

Привет,

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

введите здесь описание изображениявведите здесь описание изображения

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

Мы надеялись использовать QT State Machine Framework для пользовательского интерфейса и задавались вопросом, использовать ли несколько экземпляров конечного автомата для каждого потока/действия или использовать один «огромный» конечный автомат? Нам нужны операции unde/redo и возможно ли взаимодействие QT State-Machine Framework с QT Undo/Redo Framework?

[править] Действительно ли возможно использовать QT SM Framework для обработки взаимодействий с пользовательским интерфейсом? Какой дизайн они используют в приложениях GIMP или CAD?

Заранее спасибо, Уманга


person Ashika Umanga Umagiliya    schedule 09.07.2010    source источник
comment
Очень интересный вопрос. Я часто задавался вопросом об использовании конечного автомата Qt для управления взаимодействием с пользовательским интерфейсом.   -  person Casey    schedule 09.07.2010


Ответы (2)


Я считаю, что конечный автомат не был бы правильным выбором для представления взаимодействия с пользователем. Он подходит для простого моделирования изменений в самом пользовательском интерфейсе.

Возможно, вам понадобится комбинация конечного автомата и шаблона проектирования команд, который в Qt частично реализуется классами QUndoStack и QUndoCommand. Конечный автомат отслеживает изменения самого пользовательского интерфейса, а классы Command отслеживают взаимодействие с пользователем. Я мало что знаю об обнаружении границ ячеек и не знаю, как вы планируете модель взаимодействия в своем приложении, но позвольте мне попробовать выдуманный пример, чтобы прояснить ситуацию.

Пример

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

Затем у вас есть три разных режима взаимодействия, и у каждого есть разные действия (или инструменты), которые может использовать пользователь:

  1. По точкам. Пользователь может добавлять точки, удалять точки, перемещать точки, выбирать точки и уточнять границы.
  2. От руки. Пользователь может рисовать «карандашом» и «ластиком» и уточнять границы.
  3. Выносные примечания. Пользователь может добавить примечание, удалить примечание, переместить примечание, изменить положение стрелки примечания и изменить текст примечания.

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

Подход состоял бы в том, чтобы представить каждое из 1, 2 и 3 как состояние в конечном автомате. При входе в одно из состояний инструменты становятся видимыми. Когда состояние выходит, оно скрывает свои инструменты. Изменение состояний может быть выполнено, например, с помощью кнопок на панели инструментов.

Теперь, когда инструмент используется и изменяет модель под ним, он также сохраняет QUndoCommand в QUndoStack. Предположим, что пользователь находится в режиме от руки. Теперь она переключается в двухточечный режим, настраивает параметр, добавляет две точки, перемещает точку, а затем удаляет ее. Стек отмен может выглядеть так, снизу вверх:

  1. Переключиться с режима «от руки» на режим «точка-точка».
  2. Измените параметр ε с 0,00001 на 0,002.
  3. Добавьте точку № 1 в (120, 40)
  4. Добавьте точку № 2 в (403, 11)
  5. Переместите точку № 1 из (120, 40) в (350, 120)
  6. Удалить точку №1

Обратите внимание, что изменение состояния было добавлено в стек отмены, так что отмена последовательности команд оставляет пользователя именно там, где он был, когда вводил эту команду. Например, если бы она полностью отменила действие до 1, она вернулась бы в режим рисования от руки.

Подводя итог

  • Конечный автомат в Qt подходит для отслеживания изменений в пользовательском интерфейсе.
  • Шаблон проектирования команды подходит для отслеживания изменений, внесенных пользователем в базовую модель.
person andref    schedule 18.07.2010
comment
спасибо andref за подробный ответ. Сейчас я реализую именно так, как вы описали. Я использую конечный автомат для обработки состояний и использую QTs Undo Framework. - person Ashika Umanga Umagiliya; 21.07.2010

Мы экспериментировали с Qt State Machine Framework и Animation Framework для простых переходов пользовательского интерфейса. Я считаю, что в их документах или на их сайте есть учебные пособия или примеры того, как это сделать. Так что да, это возможно.

Я не знаю, насколько хорошо это будет масштабироваться или лучшая архитектура. Если бы это был я, я бы попытался использовать множество простых автоматов состояний, используя их иерархические возможности.

person Chris Morlier    schedule 09.07.2010
comment
+1 Я ничего не знаю о QT, но идея разбить большую проблему на более мелкие (более легко управляемые) - определенно хороший принцип для работы. - person Adrian K; 09.07.2010