Hallo Leute,
ich suche nach einem wartungsarmen und leicht erweiterbaren Aufbau für folgende Anwendung.
Ich habe zwei Hauptanwendungen A und B. Diese haben beliebig viele Tools.
Ich stelle mir jetzt die Frage ob hierfür eine Dialoganwendung oder eine Einzeldokumentanwendungen sinnvoller ist. Denke MDI ist nicht so geeigent, da jede Hauptanwendung nur einmal gestartet werden darf, welche einen Datensatz erzeugen. Jedes Tool hat wiederum mehrer widgets, welche den Datensatz verarbeiten. A, B und die Tools sollen eigene Klassen sein.
Einzeldokumentanwendungen:
Über eine Menu-Leiste, Neu, können A und B erzeugt werden und über einen Menu-Punkt Tools, die einzelnen grafischen Oberflächen für die Datensatzverarbeitung. Alles würde immer Zentralfenster stattfinden, ohne stackedLayout und stackedWidget, sprich über neue Instanziierungen.
Dialog:
Naja, hier vielleicht mit StackedWidgets arbeiten und jede Hauptanwendung und jedes Tool hat einen eigenen Dialog.
Ich persönlich tendiere eher zur Einzeldokumentanwendungen, naja weil irgendwie jede GUI so aufgebaut ist. Doofes Argument, finde ich selbst.
Vielleicht ist das ganze auch nur eine stilistische Frage, aber über Anregungen bin ich dankbar.
LG TK
Konzeptionelle Frage
Re: Konzeptionelle Frage
Ich werd aus deinem Post nicht so ganz schlau :/
Du sprichst von "Hauptanwendungen" (das ist in meinem Verständnis ein fertiges executable), die Klassen sind. Und irgendwie Dialoge für Datenbearbeitung.
Aber so ganz versteh ich dein Problem nicht. Ich nehme mal an, deine "Hauptanwendung" ist eine Sammlung von Klassen, die es ermöglichen, eine bestimmte Aufgabe zu erledigen. Du hast in den Klassen dann auch Widgets zur grafischen Darstellung und Interaktion mit dem User. Und das gleich 2x (Anwendung A und B). Haben diese beiden "Anwendungen" etwas miteinander zu tun? Weshalb muss das in einem Hauptfenster angezeigt werden? Schreib doch 2 Anwendungen. Oder verwende in einer Applikation 2 Hauptfenster.
Da du eh Widgets hast, die du irgendwie in dein Hauptfenster pflasterst, ist es doch kein großer Aufwand, einfach verschiedene Sachen auszuprobieren (MDI, Dialoge, ...). Und wenn du einen wirklich flexiblen Aufbau willst, gib dem User die Möglichkeit, die ihm angenehmste Darstellung zu wählen. So wie es z.B. der Designer anbietet.
Du sprichst von "Hauptanwendungen" (das ist in meinem Verständnis ein fertiges executable), die Klassen sind. Und irgendwie Dialoge für Datenbearbeitung.
Diese Formulierung könnte aus einer Broschüre zu irgend einer teuren Software stammen...TK hat geschrieben:ich suche nach einem wartungsarmen und leicht erweiterbaren Aufbau für folgende Anwendung.
Aber so ganz versteh ich dein Problem nicht. Ich nehme mal an, deine "Hauptanwendung" ist eine Sammlung von Klassen, die es ermöglichen, eine bestimmte Aufgabe zu erledigen. Du hast in den Klassen dann auch Widgets zur grafischen Darstellung und Interaktion mit dem User. Und das gleich 2x (Anwendung A und B). Haben diese beiden "Anwendungen" etwas miteinander zu tun? Weshalb muss das in einem Hauptfenster angezeigt werden? Schreib doch 2 Anwendungen. Oder verwende in einer Applikation 2 Hauptfenster.
Da du eh Widgets hast, die du irgendwie in dein Hauptfenster pflasterst, ist es doch kein großer Aufwand, einfach verschiedene Sachen auszuprobieren (MDI, Dialoge, ...). Und wenn du einen wirklich flexiblen Aufbau willst, gib dem User die Möglichkeit, die ihm angenehmste Darstellung zu wählen. So wie es z.B. der Designer anbietet.
Moin,
also die Hauptanwendungen haben nichts miteinander zu tun. Zwei Anwendungen kommen nicht in Frage. Meinen Satz, welchen du zitiertest, stammt aus keiner Broschüre. Dachte da nur an mein eigenes Wohl, da ab und zu eine neue Toolanfrage kommt, oder, eher seltener, eine neue Hauptanwendung. Wenn ich dann, nach ca. drei Monaten wieder mal auf den Code und die Strukturen schaue, möchte ich mich schnell wieder einfinden und nicht erst die zick Funktionsaufrufe nachverfolgen müssen. Klar, Doku ist hier auch ein Schlagwort.
Hm, nach ein Paar Überlegungen habe ich mich nun für einen Dialogstyle entschieden, also ohne Menüleiste usw. Denke, das passt.
LG TK
also die Hauptanwendungen haben nichts miteinander zu tun. Zwei Anwendungen kommen nicht in Frage. Meinen Satz, welchen du zitiertest, stammt aus keiner Broschüre. Dachte da nur an mein eigenes Wohl, da ab und zu eine neue Toolanfrage kommt, oder, eher seltener, eine neue Hauptanwendung. Wenn ich dann, nach ca. drei Monaten wieder mal auf den Code und die Strukturen schaue, möchte ich mich schnell wieder einfinden und nicht erst die zick Funktionsaufrufe nachverfolgen müssen. Klar, Doku ist hier auch ein Schlagwort.
Hm, nach ein Paar Überlegungen habe ich mich nun für einen Dialogstyle entschieden, also ohne Menüleiste usw. Denke, das passt.
LG TK
Dass das aus einer Broschüre stammt hab ich auch nicht gedacht, nur die Formulierung ist so abstrakt, allgemeingültig, dass es so geklungen hat.TK hat geschrieben: Meinen Satz, welchen du zitiertest, stammt aus keiner Broschüre.
Es sind ja auch Eigenschaften, die man sich als Entwickler und Nutzer von einer guten Software wünscht.
Wenn die Hauptanwendungen NICHTS miteinander zu tun haben, ist es in meinen AUgen alles andere als übersichtlich, diese in ein Projekt zu packen.Dachte da nur an mein eigenes Wohl, da ab und zu eine neue Toolanfrage kommt, oder, eher seltener, eine neue Hauptanwendung.
[...]
also die Hauptanwendungen haben nichts miteinander zu tun. Zwei Anwendungen kommen nicht in Frage.
Wartbarkeit und Übersichtlichkeit werden enorm darunter leiden.
Und "erweiterbare Software" definiert sich nicht durch das Hinzufügen von neuen Anwendungen, die nichts mit den bereits existierenden zu tun haben. Da gehts darum, z.B. neue Filter in ein Grafikprogramm zu integrieren, neue Sichten auf Daten einer Datenbank, oder auch ein neues Backend ala phonon.
Was ist denn deine Zielgruppe? Warum willst du überhaupt alles in eine Anwendung packen? Hilft es dir, wenn du Basisfunktionalitäten in eine Lib auslagerst, und mehrere Anwendungen gegen diese Lib linkst?
Hast du schon mal darüber nachgedacht, Plugins zu verwenden?
So etwas wäre ein Schritt in Richtung übersichtlichkeit und Erweiterbarkeit.
Die Entscheidung "MDI/Einzelfenster/Dialoge/Multiprozess/..." hat mit Erweiterbarkeit weniger zu tun.
Schau dir einfach mal Qt selber an. Da gibts einzelne Libs für bestimmte Bereiche (Gui, XML, ...), und einzelne Applikationen (assistant, designer, ...). Man kann diese Komponenten auch in eigene Anwendungen integrieren (wie deisgner/assistant in qtcreator z.B.). Kannst dir ja mal ein Szenario für dein Projekt zurecht legen.
Grüße
Franz
Die Zielgruppe erstreckt sich von Marketing-Leuten bis hin zu SW-Entwicklern.
Die Anwendung soll diverse Industrieschnittstellen bediene (CAN, Profibus usw.), aber auch µC-Interfaces wie SPI, I²C, RS232, RS485 usw. Von daher ist es nicht von Vorteil, für jede Schnittstelle eine eigene kleine App. zu schreiben, eher eine App., welche alle Schnittstellen bedienen kann.
Mit erweiteren meine ich nun, dass einfach eine neue Schnittstelle hinzukommt. Meistens sind die Schnittstellen so unterschiedlich, dass es keine Basisfunktionalitäten gibt.
LG TK
Die Anwendung soll diverse Industrieschnittstellen bediene (CAN, Profibus usw.), aber auch µC-Interfaces wie SPI, I²C, RS232, RS485 usw. Von daher ist es nicht von Vorteil, für jede Schnittstelle eine eigene kleine App. zu schreiben, eher eine App., welche alle Schnittstellen bedienen kann.
Mit erweiteren meine ich nun, dass einfach eine neue Schnittstelle hinzukommt. Meistens sind die Schnittstellen so unterschiedlich, dass es keine Basisfunktionalitäten gibt.
LG TK