Architettura dell'applicazione gui

Question

Architettura dell'applicazione gui

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Sto scrivendo un'applicazione gui. Voglio implementare la seguente struttura:

albero del progetto con nodi di diverso tipo e comportamento (ad esempio, quando si fa clic con il pulsante destro del mouse o si selezionano le opzioni del menu)
Finestra dell'editor, che può essere divisa dinamicamente in senso verticale e orizzontale, per aggiungere più aree di modifica . Ogni area di modifica corrisponde a un nodo di albero del progetto .

Sto usando c ++ / qt, ma ho il problema nella progettazione piuttosto che nella programmazione di linguaggi e librerie.

Al momento, per implementare albero del progetto ho creato un'interfaccia astratta del nodo dell'albero che contiene il link al genitore e ai bambini. Per ogni nodo di tipo specifico faccio una nuova classe. Perché sto usando Qt, ho un modello, che si comporta come un oggetto intermedio tra la vista e l'albero reale. Sembra corretto che le informazioni provenienti dalla rappresentazione visiva non possano trapelare su questo albero.

Ho i seguenti problemi con l'implementazione:

È giusto usare questo albero come titolare di tutti i miei dati? Posso usarlo per conservare informazioni sugli oggetti che sto modificando, o dovrei usare il titolare esterno per tutti i dati, ma hai un link ad esso dai miei nodi?
1. In caso di conservazione di informazioni sugli oggetti, le informazioni sulla rappresentazione visiva, già passate agli oggetti (conoscono la struttura dell'albero).
2. In caso di collegamento a un titolare esterno, non riesco a capire come creare tale collegamento e supportare la creazione / eliminazione dinamica dei nodi.
Quando faccio clic su Visualizza elemento, voglio in qualche modo rendere i dati all'interno del nodo da aprire per la modifica in area di modifica .
selezionata
1. Non riesco a capire come farlo senza dynamic_casting a un tipo specifico di nodo e passando quelle informazioni interne alla area di modifica attualmente selezionata.
2. Un altro approccio dall'aspetto negativo, che mi viene in mente è quello di introdurre la funzione virtuale nel nodo, ma il nodo non può implementare la logica di questa funzione, perché si riferisce alla rappresentazione visiva.

Esempio di albero:

I modelli sono entità che possono essere modificate dal proprio editor di grafica vettoriale, Materiali è proprietà di valori-chiave simili a tabelle, in cui ogni chiave può essere associata ad alcune primitive nell'editor grafico.

c++ architecture gui qt

posta Bhavin Chirag 20.02.2018 - 12:28

fonte

3 risposte

Leggi altre domande sui tag c++ architecture gui qt

Devo inserire comandi docker nel mio pacchetto.json? Quanto posso usare il codice di qualcun altro come fork?

score 2 · Answer 1

Se i dati stessi sono per lo più indipendenti dalla struttura ad albero, è probabilmente meglio avere una netta separazione tra interfaccia utente e dati. Quindi la risposta alla tua prima domanda

should I use external holder for all data, but have link to it from my nodes

IMHO è chiaramente "sì, assolutamente ". È necessario conservare i dati in un modello di oggetti o repository indipendente dall'interfaccia utente e disporre di ciascun nodo (che interpreto come parte dell'interfaccia utente) in possesso di un puntatore link / pointer / smart sull'oggetto correlato. Se al momento non sai come creare o gestire tali collegamenti, devi approfondire i documenti di Qt o consultare Google. Non sono un esperto di Qt, ma suppongo che tu debba ricavare una speciale sottoclasse di QStandardItem che può contenere un collegamento / puntatore intelligente all'oggetto (o qualunque oggetto Qt rappresenta i nodi dell'albero nell'interfaccia utente). Forse questo post SO più vecchio può aiutarti.

Per il tuo problema di modifica, la classe che rappresenta i nodi UI potrebbe anche contenere un secondo collegamento all'oggetto editor corretto. Quindi sarà facile implementare un metodo in quella sottoclasse che chiama l'editor corretto per i dati relativi senza il casting dinamico. Il luogo in cui devi associare l'editor corretto con l'oggetto dati corrispondente è quindi il luogo in cui vengono costruiti gli elementi del nodo dell'albero.

score 1 · Answer 2

La risposta generale a "La mia libreria GUI non contiene un componente che soddisfi tutte le mie esigenze" consiste nel combinare una raccolta di elementi della GUI che insieme fanno ciò che vuoi. Se ti senti di aver bisogno di questo in più posti, puoi comprimerlo come un nuovo componente. Solo pochissimi elementi della GUI sono interamente codificati da zero, ad es. considera come viene implementata una combo-box: è un pulsante, una modifica di riga, un menu popup e alcune connessioni.

In questo caso, puoi avere una vista ad albero ( QTreeView o QTreeWidget ) per selezionare quali dati presentare e più fotogrammi per mostrare una vista su un dato specifico ( QStackedWidget o QMDIArea ).

I dati sul nodo dell'albero devono quindi identificare i dati da tracciare. Quando la selezione cambia, la cornice pertinente sullo stack viene attivata e quindi popolata dall'origine dati

score 1 · Answer 3

Personalmente, penso che la vista ad albero non sia lo strumento giusto per questo lavoro, se ho capito correttamente il tuo modello di documento. Sembra che i tuoi "Materiali" siano simili agli stili per il testo in un elaboratore di testi. Sembra che i "Modelli" siano la carne di ciò con cui l'utente vuole lavorare e che applichino materiali ai modelli, proprio come gli stili sono applicati alle parole in un elaboratore di testi. Non ho mai visto un word processor in cui le pagine sono state mostrate nella stessa struttura ad albero con gli stili, per esempio.

Quindi vorrei prendere in considerazione la modellazione dei dati in modo simile. Avrei un oggetto documento. Il documento avrebbe una lista di materiali, ognuno dei quali ha un ID che è non il suo indice nella lista. Avrei quindi un elenco completamente separato di modelli nel documento, ei modelli farebbero riferimento ai materiali tramite il loro ID. Dissociando l'ID del materiale dalla sua posizione nell'elenco, se l'utente ne aggiunge uno nuovo tra 2 esistenti, non è necessario aggiornare tutti i modelli che utilizzano i materiali successivi.

Avrei quindi un'interfaccia utente separata per elencare i modelli e i materiali in un determinato documento. Ad esempio, in Microsoft Word, è disponibile un menu a comparsa contenente tutti gli stili di testo che è possibile applicare e un'opzione per crearne di nuovi o modificare quelli esistenti. Se questa sia l'esatta interfaccia utente di cui hai bisogno qui è discutibile, ma un modo per separarli ha senso per me. Se i tuoi materiali sono gerarchici (come il materiale B eredita tutte le proprietà del materiale A e ne aggiunge alcuni nuovi), allora una vista ad albero sarebbe appropriata solo per i materiali. In caso contrario, una sorta di elenco è appropriato: un elenco, una tabella, un menu a comparsa, una casella combinata o altro.