Организация приложения с графическим интерфейсом

Это будет общий вопрос.

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

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

Пример:

Я хочу, чтобы мое приложение можно было расширять в стиле Emacs / Vim с помощью скриптов. Ясно, что необходимо изменить какое-то общее состояние, чтобы графический интерфейс использовал его. В моем первоначальном плане была глобальная «сессия», доступная отовсюду, но я не уверен в этом.

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

Теперь компонент редактора фиксирует нажатия клавиш. У него должен быть доступ к сопоставлениям клавиш для каждого сеанса, поэтому ему нужен доступ к сеансу. Является ли привязка редактора к сеансу хорошей идеей? Другим компонентам также потребуется доступ к привязкам клавиш, поэтому сеанс теперь становится общим и может быть одноэлементным ...

Есть ли что-нибудь полезное о разработке приложений с графическим интерфейсом, выходящих за рамки MVC?

Это Python и wxPython, FWIW.

[РЕДАКТИРОВАТЬ]: добавлен конкретный вариант использования.

Почему в Python есть оператор "pass"?
Почему в Python есть оператор "pass"?
Оператор pass в Python - это простая концепция, которую могут быстро освоить даже новички без опыта программирования.
Некоторые методы, о которых вы не знали, что они существуют в Python
Некоторые методы, о которых вы не знали, что они существуют в Python
Python - самый известный и самый простой в изучении язык в наши дни. Имея широкий спектр применения в области машинного обучения, Data Science,...
Основы Python Часть I
Основы Python Часть I
Вы когда-нибудь задумывались, почему в программах на Python вы видите приведенный ниже код?
LeetCode - 1579. Удаление максимального числа ребер для сохранения полной проходимости графа
LeetCode - 1579. Удаление максимального числа ребер для сохранения полной проходимости графа
Алиса и Боб имеют неориентированный граф из n узлов и трех типов ребер:
Оптимизация кода с помощью тернарного оператора Python
Оптимизация кода с помощью тернарного оператора Python
И последнее, что мы хотели бы показать вам, прежде чем двигаться дальше, это
Советы по эффективной веб-разработке с помощью Python
Советы по эффективной веб-разработке с помощью Python
Как веб-разработчик, Python может стать мощным инструментом для создания эффективных и масштабируемых веб-приложений.
9
0
791
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Если вы посмотрели на MVC, вы, вероятно, двигаетесь в правильном направлении. MVC, MVP, пассивный просмотр, контролирующий контроллер. Это разные способы, каждый со своими плюсами и минусами, для достижения того, что вам нужно. Я считаю, что пассивный просмотр является «идеальным», но он заставляет вас вводить слишком много виджетов в ваши графические интерфейсы (например, интерфейс IInterface). В общем, я считаю, что контролирующий контроллер - хороший компромисс.

В MVC Модель заполняет является общим состоянием информации.

Элемент управления - это общее состояние настроек управления графическим интерфейсом пользователя и ответов на щелчки мыши и тому подобное.

Ваш угол сценария может

1) Обновите объекты модели. Это хорошо. Элемент управления может быть «наблюдателем» за объектами модели, а вид можно обновлять, чтобы отразить наблюдаемые изменения.

2) Обновите объекты Control. Это не очень хорошо, но ... Затем объекты Control могут вносить соответствующие изменения в модель и / или представление.

Я не уверен, в чем проблема с MVC. Не могли бы вы представить более подробный пример дизайна с конкретными проблемами или проблемами?

Ответ принят как подходящий

Извините, что так поздно перескакиваю на этот вопрос, но ничего, я имею в виду, что ничего такого может лучше взглянуть на источник приложения, которое делает нечто подобное. (Я мог бы порекомендовать что-то вроде http://pida.co.uk, но существует множество расширяемых IDE wx + Python, поскольку это похоже на то, что вы делаете).

Сделаю несколько замечаний:

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

  2. общее состояние по своей сути не является плохим, но я бы согласился с вашим чутьем и использовал как можно меньше. Поскольку сама Вселенная имеет состояние, вы не можете полностью избежать этого. Я предпочитаю использовать общий объект «Boss», который обычно не является одиночным экземпляром для каждого приложения и отвечает за посредничество с другими компонентами.

  3. Для сочетаний клавиш я обычно использую какую-то систему «Действия». Действия - это вещи высокого уровня, которые может делать пользователь, например: «Сохранить текущий буфер», и они могут быть удобно представлены в пользовательском интерфейсе кнопками панели инструментов или элементами меню. Итак, ваши скрипты / плагины создают действия и регистрируют их с помощью чего-то центрального (например, какого-то объекта реестра - см. 1 и 2). И на этом их участие заканчивается. Вдобавок к этому у вас есть своего рода служба привязки ключей, которая сопоставляет ключи с действиями (которые он перечисляет из реестра, для каждого сеанса или иным образом). Таким образом, вы добились разделения кода плагина и привязки клавиш, разделения редактора и кода действия. В качестве дополнительного бонуса ваша задача «Настроить ярлыки» или «Определенные пользователем карты клавиш» станет особенно проще.

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

Другие вопросы по теме