Quali sono alcuni metodi di progettazione standard per aggiungere GUI a un'app della riga di comando? [chiuso]

Potrei darti alcune linee guida approssimative su come creare la GUI equivalente per un'applicazione CLI, dal punto di vista del design. Come faresti effettivamente le chiamate è fuori dallo scopo di questa risposta.

• opzioni come -p -v ecc sono checkbox

• opzionimutuamenteesclusivesonoungruppodipulsantidiopzione

I parametri
• che sono un nome file sono una casella di testo con un pulsante "scegli" che mostra una finestra di dialogo Scegli file quando premuto

Iparametristringa
• ingeneralesonocaselleditesto
Iparametridelnumero
• possonoesserecaselleditesto,casellecombinateocasellediselezione,asecondadeivalorinoti,essendoristrettiinunintervallooinunaformalibera.

• gliusitotalmentedivergentisonoseparatiinschede(adesempioaggiungendoilmeta-switch"commit" a git, cambia l'intero insieme di parametri e parametri previsti / permessi)

• Unavoltainseritiiparametri,unpulsanteeseguel'azione

Nota: la convalida dell'input deve essere proattiva , ovvero, è necessario impedire all'utente di eseguire l'azione quando i parametri obbligatori non sono stati immessi, annullando il pulsante di esecuzione e, in genere, l'oscuramento o attivazione degli elementi della GUI al fine di trasmettere un uso corretto. Nelle app CLI, l'utente esegue semplicemente il comando e riceve un messaggio di errore, ovvero la convalida è reattiva.

Di solito, questo può essere risolto scrivendo un front-end della GUI che costruisce una riga di comando . A quel punto si chiama semplicemente la vecchia funzione "main ()" della CLI con gli argomenti nell'ordine appropriato.

Ciò che devi fare, dipende dall'output. Potresti fare bene avvolgendo tutto printf() in una generica funzione di output variabile, che nella versione CLI passerà il controllo a printf mentre nella versione GUI manda l'output a una finestra di log scrolldown o qualcosa del genere.

In questo modo, l'applicazione CLI è per lo più invariata e il front-end della GUI, pur perdendo in efficienza, rimane liberamente accoppiato e può essere mantenuto indipendentemente (in alcuni casi, un mockup - o anche una alternativa reale alla GUI - potrebbe essere un'applicazione indipendente che poi genera il binario CLI con gli argomenti appropriati, una specie di cosa si può fare con AutoIt su Windows, per così dire).

Ma questo dipende strongmente da ciò che l' in realtà effettivamente . Questo approccio può ancora essere perseguito in misura maggiore o minore, ma potrebbe diventare imbarazzante se, ad esempio, si volesse eseguire la routine CLI ciclicamente o qualcosa del genere; o se il programma prevede di operare su un input da stdin .

la prima cosa che vuoi fare è rendere il back-end (dietro l'attuale CLI) separato dal frontend (la CLI)

separa essenzialmente la vista / controller (CLI) dal modello in modo che tutto il codice di funzionalità possa essere separato nel suo modulo autonomo (che puoi compilare in una lib statica per esempio)

allora puoi usare l'interfaccia pubblica C di quel modulo per eseguire il codice nella tua GUI QT

per la correlazione delle pressioni dei pulsanti c'è un'implementazione estesa dello slot di segnale in QT e QT creator gestirà molto del binding per te (è semplice come fare clic con il tasto destro del mouse - vai allo slot ...- & gt ; clicked () - > type foo() )

Se l'applicazione CLI corrente utilizza un formato di input e output ragionevolmente strutturato (in particolare l'output.) Dovrebbe essere strutturato abbastanza per essere analizzato da una macchina), quindi è sempre possibile creare un'applicazione GUI separata che comunichi con l'applicazione CLI attraverso pipe e / o file temporanei.

Per integrare la GUI con l'applicazione corrente, devi essere in grado di separare completamente la gestione I / O dal resto dell'applicazione, così puoi costruire la parte I / O-less come libreria e avvitare un utente interfaccia (o GUI o CLI) su quella. Se l'applicazione originale non è mai stata progettata per questo, potrebbe essere un compito difficile, perché è così facile sparpagliare% chiamate diprintf dappertutto.

Il fatto che Qt sia C ++ e l'applicazione sia in C non dovrebbe costituire un ostacolo principale per un'applicazione integrata, a patto che l'interfaccia alla parte back-end sia scritta nel sottoinsieme comune di C e C ++. Quindi devi solo superare la curva di apprendimento del C ++.