Любая практическая альтернатива модели Signals + Slots для программирования GUI?

Большинство GUI Toolkits в настоящее время используют модель Signals + Slots. Это были Qt и GTK +, если я не ошибаюсь, кто это сделал.

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

Теперь, насколько я знаю, этот дизайн используется в большинстве современных инструментов. Есть Qt, GTK +, FLTK и т. Д. Есть Java Swing. В C # даже есть языковая функция (события и делегаты), и Windows Forms была разработана для этого дизайна. Фактически, за последнее десятилетие этот дизайн для программирования GUI стал своего рода неписаным стандартом. Так как это увеличивает производительность и обеспечивает большую абстракцию.

Тем не менее, мой вопрос:

Есть ли альтернативный дизайн, параллельный или практичный для современного программирования GUI?

Т.е. дизайн Signals + Slots - единственный практичный в городе? Реально ли программирование GUI с любым другим дизайном? Существуют ли какие-либо современные (желательно успешные и популярные) GUI-инструментарии, основанные на альтернативном дизайне?

Хотя я бы не назвал это все таким популярным, всегда есть реактивное программирование для графических интерфейсов, особенно функциональное реактивное программирование , реализуемое, например, с помощью .NET Rx Framework , а также с помощью нескольких наборов инструментов на несколько более эзотерических языках / платформах. Как реактивный банан или FrTime , для Haskell и Racket соответственно.

Это мой любимый предмет, и в течение примерно десяти лет (с 70-х по 86-й) я думал, что наличие GUI, состоящего из объектов, которые реагируют на события, было правильным способом сделать это.

Затем я наткнулся на другой способ сделать это, описанный здесь, и с проектом sourceforge здесь .

В двух словах, проблема с объектами состоит в том, что они сохраняются, и если вы пишете код для их создания, вам также придется писать код для их постепенного изменения, если изменения необходимы, и каким-то образом получать сообщения от них. Разве не было бы неплохо, если бы вы могли просто нарисовать то, что вы хотели, а затем перекрасить это, если вы хотите что-то другое, и вам не нужно беспокоиться о сохранении предыдущих объектов? Разве не было бы неплохо, если бы вам никогда не приходилось писать код для обработки сообщений, потому что все это делается изнутри?

Это то, что делает этот пакет. Для простых диалогов это сохраняет порядок величины в коде. Для сложных динамически изменяющихся диалогов это возможно.

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

Ну, есть два разных способа сделать это:

1. Пусть каждый виджет предоставляет детализированный механизм подписки (Сигнал / Слот, Наблюдатель / Наблюдаемый, Событие / Делегат), а клиентский код подписывается и предпринимает соответствующие действия.
2. Создал виджет против абстракции данных, которые он представляет, и клиентский код реализовал эту абстракцию.

Вот пример для второго подхода:

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

И теперь вы можете создать код LabelButtonпротив а, LabledActionа клиент может просто реализовать его или использовать некоторую стандартную реализацию по умолчанию, если она доступна и подходит.

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

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