Qualche alternativa pratica al modello Signals + Slots per la programmazione della GUI?

La maggior parte dei toolkit GUI oggigiorno utilizza il modello Signals + Slots. Sono stati Qt e GTK +, se non sbaglio, a fare da pionieri.

Sai, i widget o gli oggetti grafici (a volte anche quelli che non sono visualizzati) inviano segnali al gestore del ciclo principale. Il gestore del ciclo principale chiama quindi gli eventi , i callback o gli slot assegnati per quel widget / oggetto grafico. Di solito ci sono virtualgestori di eventi predefiniti (e nella maggior parte dei casi ) già forniti dal toolkit per gestire tutti i segnali predefiniti, quindi, a differenza dei progetti precedenti in cui lo sviluppatore doveva scrivere l'intero ciclo principale e il gestore per ogni messaggio stesso (pensa WINAPI), lo sviluppatore deve solo preoccuparsi dei segnali su cui ha bisogno per implementare nuove funzionalità.

Ora, per quanto ne so, questo design viene utilizzato nella maggior parte dei toolkit moderni. Ci sono Qt, GTK +, FLTK ecc. C'è Java Swing. C # ha persino una funzione linguistica (eventi e delegati) e Windows Forms è stato sviluppato su questo progetto. In effetti, nell'ultimo decennio, questo progetto per la programmazione della GUI è diventato una specie di standard non scritto. Dal momento che aumenta la produttività e fornisce una maggiore astrazione.

Tuttavia, la mia domanda è:

Esiste un design alternativo, parallelo o pratico per la moderna programmazione della GUI?

vale a dire il design Signals + Slots è l'unico pratico in città? È possibile eseguire la programmazione della GUI con qualsiasi altro design? Sono disponibili toolkit moderni (preferibilmente di successo e popolari) basati su un design alternativo?

Anche se io non lo chiamerei tutto quello popolare, c'è sempre la programmazione reattiva per GUI, in particolare la programmazione reattiva funzionali , come attuato, ad esempio, da parte del .NET Framework Rx , oltre che da diversi toolkit in lingue un po 'più esoterici / piattaforme , come reattivo-banana o FrTime , rispettivamente per Haskell e Racket .

Questo è il mio argomento preferito e per circa un decennio (dagli anni '70 al '86) ho pensato che avere una GUI composta da oggetti che rispondessero agli eventi fosse il modo giusto per farlo.

Poi mi sono imbattuto in un altro modo per farlo descritto qui e con un progetto sourceforge qui .

In poche parole, il problema con gli oggetti è che persistono e, se si scrive codice per crearli, è necessario anche scrivere codice per modificarli in modo incrementale se sono necessarie modifiche e in qualche modo ottenere messaggi da e verso di essi. Non sarebbe bello se tu potessi semplicemente dipingere ciò che volevi e poi ridipingerlo se vuoi qualcosa di diverso e non devi preoccuparti della persistenza degli oggetti precedenti? Non sarebbe bello anche se non dovessi mai scrivere codice per la gestione dei messaggi, perché è tutto fatto sotto il cofano?

Questo è quello che fa quel pacchetto. Per dialoghi semplici, salva un ordine di grandezza nel codice. Per dialoghi complessi che cambiano dinamicamente, li rende possibili.

PS L'ho fatto solo per le interfacce utente desktop e le interfacce terminale remoto, non per le interfacce browser web. Sono sicuro che è possibile, ma non ho avuto la possibilità di provarlo.

Bene, ci sono due modi distinti per farlo:

1. Fai in modo che ogni widget esponga un meccanismo di sottoscrizione granulare (segnale / slot, osservatore / osservabile, evento / delegato) e abboni il codice client e agisca di conseguenza.
2. Costruito un widget contro un'astrazione dei dati che presenta e il codice client implementa tale astrazione.

Ecco un esempio per il secondo approccio:

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

E ora puoi creare un LabelButtoncontro un LabledActioncodice client e puoi semplicemente implementarlo o utilizzare un'implementazione predefinita generica, se disponibile e adatta.

In un certo senso il secondo approccio è meno flessibile, ma più rigido. In qualche modo non si collega semplicemente la vista con il modello con mezzi relativamente atomici. Si progetta una GUI adatta in base alle proprie esigenze e quindi si implementano gli adattatori tra quella GUI e la logica del dominio / dell'applicazione.

Alcuni sistemi di tipo di controllo utilizzano un approccio al database: ogni controllo GUI è collegato a un file archiviato nel database in modo che la GUI rifletta sempre lo stato del database. Gli hook DB vengono utilizzati per attivare le funzioni quando un valore cambia.