Gestire la durata degli stati della GUI

0

Sto progettando un programma responsabile di una GUI (con la grafica e l'input dell'utente gestito in un tipico ciclo di aggiornamento) che ha diversi stati:

  • Lo stato predefinito è un'animazione che viene continuamente eseguita nonostante qualsiasi input dell'utente.

  • È possibile richiamare uno stato di notifica che visualizza una notifica anziché l'animazione. Le notifiche hanno un timeout che dovrebbe auto-chiudersi dopo quell'ora e tornare all'animazione predefinita, potrebbe anche essere chiuso prematuramente dall'input dell'utente o da un'altra notifica di maggiore priorità.

  • Esiste anche una modalità di presentazione che riproduce un video clip e dovrebbe chiudersi automaticamente e tornare allo stato predefinito al termine. Tuttavia, una notifica importante può anche mettere in pausa il video ed essere visualizzato, dopo di che il video dovrebbe riprendere e tornare all'animazione predefinita una volta che finisce.

Altri stati sono previsti in futuro anche se i loro requisiti non sono ancora stati definiti. Ma come puoi vedere, l'architettura dovrebbe essere estensibile con la possibilità di aggiungere più stati. Pertanto, ogni stato dovrebbe essere in grado di controllare il proprio ciclo di vita e le modifiche di stato invocate per la GUI. Per ogni transizione di stato, lo schermo dovrebbe anche dissolvere lo stato corrente e affrontare quello successivo.

La mia domanda è: quale tipo di architettura OOP può essere utilizzata per ottenere questo risultato (al contrario delle istruzioni if / then nel ciclo di aggiornamento)? Ci sono schemi di progettazione (forse pattern di stato) che possono raggiungere questo obiettivo?

Nota: è in fase di sviluppo con SFML e c ++.

    
posta Andrew Murtagh 22.03.2018 - 23:58
fonte

2 risposte

1

Potresti usare lo schema di stato, ma visto che ora si presenta come una semplice app con un paio di visualizzazioni - non sono sicuro che implementare una macchina a stati espliciti ne valga la pena, ma dipende dalle capacità della tua struttura della GUI.

Se in realtà è un bare-bones e hai un ciclo di rendering per il disegno ecc. allora sì, potrebbe valerne la pena, ma se il framework è di livello superiore e facilita lo scambio di viste ecc. non mi preoccuperei.

    
risposta data 20.08.2018 - 10:00
fonte
0

Lo schema di stato sembra certamente un candidato per i diversi "schermi" e le loro transizioni. Poiché devi dissolvenza incrociata, dovresti variare leggermente, avendo uno stato "attivo" e uno stato "obsoleto" (o precedente) durante la dissolvenza (entrambi si animano, ma solo l'attivo avrebbe un comportamento o reazione agli eventi dell'interfaccia utente).

Vorrei seriamente riconsiderare il funzionamento continuo di un loop. Questo probabilmente metterà l'uso della CPU al 100%. Anche con un loop, l'opzione migliore sembra "addormentare" il processo alcuni millisecondi e rilascia aggiornamenti a intervalli regolari (si otterrebbero comunque animazioni belle e fluide, ma riducendo notevolmente l'utilizzo della CPU). Quindi, sia per il "segno di animazione" che per gli altri eventi dell'interfaccia utente, il modello di Osservatore aiuterà. Uno dei vantaggi che otterresti è che puoi persino decidere di animare o meno animare determinati elementi in modo dinamico semplicemente iscrivendoli o cancellandoli agli eventi di "animazione tick". Puoi ignorare l'animazione di un widget nascosto nella sua funzione redraw , ma non è necessario nemmeno chiamare quella funzione in primo luogo! ;)

    
risposta data 23.03.2018 - 00:15
fonte

Leggi altre domande sui tag