GUI Handcode o utilizzare lo strumento gui-designer

Question

Mi piacerebbe sentire alcune opinioni sulla codifica manuale delle interfacce grafiche come si fa tipicamente quando si utilizza Java o Qt con C++, vs utilizzando uno strumento gui-designer? Esempi di strumenti di progettazione GUI sarebbero MFC GUI-designer, Qt designer, Interface Builder (Apple).

Ero un fan della codifica manuale, ma dalla recente esperienza sono passato. Il problema che ho riscontrato con la codifica manuale è che è abbastanza veloce e flessibile scrivere le GUI, ma una volta che è necessario apportare una modifica a una GUI scritta molto tempo fa, può essere molto difficile. Trovare l'elemento giusto nel grande pannello può essere difficile.

Il secondo problema è che rende fin troppo facile aggiungere molta logica nella creazione della GUI e nel codice di layout. Ho spesso dovuto occuparmi della manutenzione del codice GUI, che è davvero difficile da riutilizzare perché il suo comportamento è mescolato con il suo aspetto e il layout e il comportamento di mix rendono spesso la classe molto ampia e difficile da comprendere.

L'utilizzo di uno strumento di progettazione GUI consente di ottenere una separazione molto più chiara tra l'aspetto e la logica.

Answer 1

Sono fermamente convinto che dovresti usare un generatore di interfaccia invece di codificare a mano una GUI. Come nella domanda menzionata è una separazione molto più pulita e una volta che qualcosa deve essere modificato è molto più facile.

Il Designer di Qt ha questa funzione per creare una classe da un file di .ui ₁₎, ma penso che non si utilizza questa funzione è il modo migliore, in quanto questo crea solo più codificato che non dovrebbe esistere . Il problema della velocità di creazione della finestra da un file .ui è trascurabile perché la finestra deve essere caricata una sola volta.

Questo è PyQt, ma qualcosa di simile è possibile in C++:

class SelectDateDialog(QDialog): 
    def __init__(self): 
     QDialog.__init__(self) 
     uic.loadUi("resources/SelectDate.ui", self) 

Essenzialmente questo ha lo stesso effetto come comprendente tutte le vostre UI-codice nel metodo di __init__(), ma l'interfaccia utente è quasi completamente separata dalla codice.

¹⁾.ui sono file XML che descrivono un'interfaccia utente

Answer 2

Dipende dalla situazione, davvero. Penso che entrambi abbiano il loro posto, e di solito uso un approccio ibrido.

Ci sono sempre alcune cose che il generatore GUI non può fare (ad esempio l'impostazione del colore su una costante UIColor in Interface Builder). D'altra parte, la maggior parte delle operazioni di interfaccia utente è piuttosto banale (ad esempio, aggiungendo etichette statiche).

Preferisco fare le cose banali nel builder della GUI e le cose più interessanti nel codice.

Inoltre, occasionalmente mi trovo a modificare manualmente l'XML prodotto dal builder della GUI (Interface Builder e glade nel mio caso).

Answer 3

Abbastanza divertente è andato il contrario per me. Parlando dal punto di vista di Winforms, il codice generato dal designer è piuttosto rumoroso, con forse un quarto o metà di tutte le impostazioni di proprietà davvero necessarie. Fare controlli piuttosto grandi è anche più una tentazione quando si lavora con un designer. Cambiare una certa gerarchia di controlli nel designer di Winforms è un vero incubo ai miei occhi.

Nel mio ultimo progetto ho creato API aggiuntive per configurare splitter in moduli, portuali, menu, barre degli strumenti ecc. In modo dichiarativo. Questi sono tali che rafforzeranno ulteriormente la separazione delle preoccupazioni.

Inoltre, provo a fare molto più affidamento sulle funzionalità di impaginazione automatica, che sono sicuramente molto più belle in WPF, ma possono anche andare in qualche modo in Windows Form.

Answer 4

La mia opinione su questo: 1. codice della GUI Hand-coded è molto più riutilizzabile 2. problemi di layout sono più semplici con i progettisti

Answer 5

caldamente consigliamo di utilizzare Interface Builder su OS X. Farlo da la mano va bene se vuoi imparare, ma ti stai risparmiando un sacco di mal di testa usandolo su progetti reali. È davvero piuttosto potente.

Come per Java e C++, dipende da cosa stai facendo e su quali piattaforme. Per le applicazioni semplici è possibile evitare di vedere il codice dell'interfaccia utente. Tuttavia, per applicazioni complicate e rich client, in genere devi eseguire parte del codice a mano.

Answer 6

avrei sempre a mano il codice della progettazione grafica dove non esiste uno standard (o de-facto standard) linguaggio di markup GUI (come con Java). La ragione di questo è che ho scoperto che usin uno strumento di progettazione di builder GUI ti legherà a utilizzare un particolare IDE. Nel tempo, il miglior IDE per la progettazione e/o la scrittura del codice GUI cambierà e ogni sviluppatore dovrebbe essere libero di scegliere quale IDE si senta più a suo agio con.

Dove lavoro al momento, abbiamo un sacco di interfacce grafiche legacy che sono state scritte utilizzando NetbeansMatisse GUI builder (contro il mio consiglio al momento :-). Questi sono ora quasi irrinunciabili perché tutti gli sviluppatori preferiscono o IntelliJ IDEA o Eclipse come IDE. Non è realistico o praticabile che gli sviluppatori attivino Netbeans solo per modificare il layout della GUI (le persone non mantengono sincronizzate le definizioni dei progetti Netbeans, ecc.).

Un altro punto è che il tempo totale di scrittura del codice di layout GUI è probabilmente solo il 5% dello sforzo di sviluppo totale di un determinato progetto. Anche se ci vuole il doppio del tempo per scrivere il codice da solo, questo non si traduce in un sovraccarico nel grande schema delle cose. Ed è un piccolo prezzo da pagare per la manutenibilità a lungo termine.

Fintantoché non si ha la certezza di separare la logica di layout della GUI dalla logica aziendale, non credo che ne risenta qualcosa. Nessuno qui usa più i costruttori GUI!

Answer 7

Lo faccio a mano, è molto più semplice mescolare le cose intorno e riutilizzare i pannelli all'interno dell'applicazione (alcuni pannelli possono apparire in più punti).

L'utilizzo di un designer funziona quando sei in una squadra che gli artisti devono fare la GUI.

Trovare l'elemento giusto nel pannello grande può essere difficile.

?? Non l'ho mai visto.

Answer 8

Tendo a pensare che la risposta giusta dipenda dalla cultura della piattaforma di destinazione. Su OS X, Interface Builder è una parte così integrante della catena di strumenti che è difficile evitarlo.

In Java (awt o swing), è vero il contrario. Non esiste un supporto per toolchain per questo.

In realtà, il modo in cui puoi dire è il modo in cui gli strumenti producono le loro uscite. Interface Builder produce file in formato .nib specifici per il modo in cui Cocoa mette i controlli sullo schermo. Comprende ciò che è essenzialmente un formato di markup dell'interfaccia. Java non ha un concetto simile. Tutto è una classe compilata e quindi è molto più difficile ottenere risultati convenienti.

GTK +, quando combinato con radura, sembra raggiungere un ragionevole equilibrio tra i due.

Answer 9

Nulla impedisce di mescolare i due approcci. Spesso faccio il layout principale di un modulo in un progettista della GUI (perché è veloce e vedi cosa stai facendo), e metto lì uno o più pannelli che vengono poi popolati con il codice. Ciò è particolarmente utile quando la GUI deve adattarsi a situazioni specifiche, ad esempio se la GUI deve cambiare in base all'hardware connesso.

In ogni caso, la cosa più importante è in effetti mantenere la GUI e la logica dell'applicazione separate.

Answer 10

codifica manuale può essere buono se si desidera alcune funzioni non standard inclusi in voi UI. Hai una maggiore flessibilità, ma dovrai investire più tempo per creare una buona interfaccia, perché Java/C++ non è un linguaggio per la progettazione dell'interfaccia utente.

Sul lato positivo se si dispone di un controllo di revisione è possibile osservare la cronologia delle modifiche, cosa che non può essere eseguita con un progetto che utilizza un formato binario o un formato xml che non sia compatibile con RCS.

Oggi la maggior parte degli strumenti disponibili per la progettazione visiva di un'interfaccia utente mancano di alcune funzionalità. Non sono abbastanza flessibili, alcune caratteristiche possono essere raggiunte solo codificandole. Inoltre, in alcuni casi il codice generato non è realmente umano e se modifichi a mano potresti non essere più in grado di continuare a utilizzare il designer.

Ma il design può essere davvero un risparmio di tempo se il design è semplice, e possiamo sperare che i progettisti saranno migliorati in futuro, ma non terremo per ampiezza.

La mia conclusione è che se avete bisogno di flessibilità oggi dovrete codificare a mano l'interfaccia, se volete qualcosa di semplice e veloce allora il progettista è la scelta migliore.

Forse in futuro i progettisti saranno più potenti, o forse ci saranno nuovi linguaggi specializzati nella progettazione dell'interfaccia utente che saranno più adatti per l'uso in C++/Java, qualcosa come XUL o XAML.

Answer 11

Se si sta progettando un'applicazione aziendale con molti moduli di immissione e dati tabulari, la scrittura del codice per l'interfaccia utente è sia più rapida e più gestibile rispetto all'utilizzo di un progettista dell'interfaccia utente. In questi tipi di applicazioni, non c'è quasi mai bisogno di posizionare precisamente un elemento in un punto predefinito sullo schermo, mentre d'altra parte, ci sono un sacco di convenzioni di ripetizione e progettazione che possono essere semplicemente estratte in metodi separati.

Prendiamo ad esempio una finestra di dialogo delle preferenze di Eclipse o di OpenOffice. Ci sono un sacco di categorie e un sacco di diverse opzioni da impostare per ciascuna. Se devi fare qualcosa di queste dimensioni, disegnare a mano ogni schermo è un compito banale. Un approccio molto migliore è scrivere codice che genererà elementi UI al volo, dai dati di dominio forniti, secondo alcune convenzioni e impostazioni predefinite.

Non vedo come l'utilizzo di un designer faciliti una migliore separazione, né come quella separazione percepita possa essere d'aiuto con qualsiasi cosa, dato che hai già mantenuto la tua logica aziendale fuori dall'interfaccia utente.

E, infine, se stai usando Java, assicurati di controllare MigLayout. Funziona con Swing e SWT, la sua 'sintassi' è molto concisa e chiara, e ha una modalità di debug che è incredibilmente utile.