Das deutsche Python-Forum

Hi, ich hätte eine generelle Frage zur Vorgehensweise bei der Programmierung von GUIs. Es geht zwar im speziellen um PyQt, sollte aber bei allen anderen Toolkits genauso gelten, deshalb hab ich es in Allgemeine Fragen gepostet.

Generell geht es darum wie man eine komplexere GUI in mehrere Dateien aufsplittet. Ein Beispiel: Ein Editor für unterschiedliche Arten von Daten. Der Editor hat als Zentrales Widget Tabs für die offenen Daten.

Wie kann ich jetzt für jeden Datentyp einen eigenen Editor schreiben, diesen in eine eigene Datei legen und anschließend beim Erstellen einer neuen Datei den entsprechenden Editor als neuen Tab einfügen? Dazu kommt noch das die Editoren eine Möglichkeit haben sollen eigene Toolbars, Menus oder Dock Widgets hinzuzufügen

Oder allgemeiner ausgedrückt: ich möchte im Hauptframe die Container verwalten, den Inhalt der Container aber in eigenen Dateien schreiben. Gleichzeitig sollen die Container Daten zum Hauptframe hinzufügen können. Wie geht man da vor?

wie wäre es mit einer datei datentypen mit mehrewren classen die dann die objekte bekommen.
somit wird nur eine datei importiert

@sea-live: burli möchte ja gerade *nicht* alles in einer Datei haben.

@burli: Editoren in eigene Module stecken und dann entweder beim einzelnen Editor Methoden zur Verfügung stellen, von denen die Haupt-GUI abfragen kann, was sie in die Menüs und Toolbars noch so hinzufügen soll, oder der `__init__()` der Editoren eine Referenz auf die Haupt-GUI mit geben, damit der einzelne Editor selber auf die Menüs usw. Zugriff bekommt.

@sea-live: eben, ich möchte es vermeiden eine Datei unnötig aufzublasen. Es reicht schon wenn die Klasse des Formular in einer Datei steht.

@BlackJack: die zweite Variante dürfte die bessere sein. Ich hab auch schon überlegt GUI und Logik zu trennen. Müsste mir vielleicht mal MVC anschauen. Aber ich glaub das ist sekundär

burli hat geschrieben:Ich hab auch schon überlegt GUI und Logik zu trennen.

Ich glaube, das sollte man sich nicht nur überlegen, sondern es ist sehr zu empfehlen. Gerade wenn du die Oberfläche mit dem Qt Designer baust, wird ja ohnehin jedes Mal eine neue Datei geschrieben (bzw die alte überschrieben). Das heißt du müsstest in dem Fall erst das komplette Design schreiben und dann die Logik in die Datei einfügen (denn ansonsten würde sie ja überschrieben werden). Und das ist ja eigentlich etwas, das man gerade *nicht* möchte. Also geht man eher so vor (zumindest mache ich das so), dass der logische Teil den grafischen Teil später importiert und somit beide unabhängig voneinander sind.

Ich überlege noch ob und wieviel ich mit dem Designer mache. Aber das ist schon richtig. Mit dem Designer ne GUI erzeugen und dann da drin editieren ist irgendwie sinnlos. Mal schauen wie ich das anstelle

Nicht nur das, auch Logik und GUI generell.
Pack die GUI in eine eigene Klasse oder gleich Datei - gerade wenn du den Designer benutzt. Das macht das Programm leichter wartbar, weil du nicht soviele Fallstricke damit aufbaust.

Übrigens würde ich ja raten, nicht den Designer den Code generieren lassen sondern die Dateien des Designers einzubinden, wie das eigentlich in jedem modernen Toolkit möglich ist (und sogar weniger modernen, wie das was Windows da bietet). Wie das bei Qt genau möglich ist, das schaut ihr in der Dokumentation nach oder in Lunars Programmen.

Ist auch ne Möglichkeit. Sind nix anderes als XML Dateien oder sowas. Allerdings generiert die "Compilierung" auch gleich Code zb für die Übersetzung der Sprache.

Aber wie gesagt, ich halte den Designer nur bedingt für tauglich. Hauptsächlich für Dialoge oder einfache Frames ist der sinnvoll. Wenn es umfangreicher wird ist Coden von Hand glaub ich besser. Aber das muss ich mal austesten

Wann ist ein Frame denn für dich ein "einfaches" Frame und ab wann könnte der Designer deiner Meinung nach überfordert sein? Ich habe große Schwierigkeiten, deine gerade gemachte Aussage nachzuvollziehen. Aber vielleicht gibt ja bestimmte Dinge, auf die man bei großen GUIs achten muss, von denen ich nichts weiß.

Mit einem Designer kann man schon sehr viel machen. Viele Kritiker monieren, dass man bei extrem dynamischen GUIs eh vieles per Hand designen muss und man sich deswegen dann auch den Designer für das "bischen" drum herum sparen kann.

Ich sehe das anders. Das "bischen" drum herum ist oftmals das, was eine GUI strukturierter gestaltet und wofür es durchaus brauchbare Templates für einen Designer gibt (Stichwort Menüleiste usw). Desweiteren lassen sich auch die dynamischen Elemente früher oder später in atomare Bereiche untergliedern. Diese kann man ja auch per Designer erstellen und dann zur Laufzeit dynamisch in die restliche GUI einbauen. Auch hier kann man dann später alle Vorteile des Designers nutzen, ohne sich imho irgend welche Nachteile einzufangen.

Ich glaube viele dieser Vorurteile kommen aus der Java-Welt, in der es ja zum guten Ton von Designern gehört, direkt Code zu generieren und darin herumzupfuschen. Das hat mir bisher unter Java auch den "Spaß" an GUIs verdorben - sofern GUIs überhaupt Spaß machen

Naja, für den Hauptframe brauche ich ne Menuleiste, ne Toolbar und die Statuszeile. Die sind mehr oder weniger leer. Dafür brauche ich nicht unbedingt einen Designer.

Aber vielleicht wird es dann interessant wenn man eine mehrsprachige Anwendung programmiert, die Ressourcen nutzt usw.

Ich gebe zu das ich noch lange nicht alles weiß, speziell was der Designer alles kann und wie man damit umgeht. Vielleicht lerne ich die Vorteile ja noch kennen

burli hat geschrieben:Naja, für den Hauptframe brauche ich ne Menuleiste, ne Toolbar und die Statuszeile. Die sind mehr oder weniger leer. Dafür brauche ich nicht unbedingt einen Designer.

Also wenn ich sehe, was mir der Designer da schon alles an Zeugs ausspuckt, nur um ein simples QtMainWindow auf den Schirm zu zaubern, möchte ich das nicht alles per Hand machen Vor allem weißt Du u.U. noch nicht einmal, was Du noch alles brauchst. Später willst Du evtl. Menüpunke hinzufügen usw und das geht dann per Editor imho schneller und bequemer.

Hyperion hat geschrieben:Später willst Du evtl. Menüpunke hinzufügen usw und das geht dann per Editor imho schneller und bequemer.

Das ist das gleiche wie die Diskussion ob eine GUI oder eine Konsole schneller/besser ist. Jeder wie wer meint . Wenn man den Dreh erstmal raus hat ist es denke ich auch von Hand kein Problem schnell Änderungen vorzunehmen

burli hat geschrieben:Naja, für den Hauptframe brauche ich ne Menuleiste, ne Toolbar und die Statuszeile. Die sind mehr oder weniger leer. Dafür brauche ich nicht unbedingt einen Designer.

Aber gehört nicht genau das zu den "einfachen" Frames, von denen du vorher gesprochen hast und wo der Designer angeblich geeigneter wäre? Ich möchte dir den Designer sicher nicht aufzwingen, aber zumindest bei der Argumentation sollte man sich doch iim Klaren darüber sein, wofür man denn nun eigentlich plädieren will.

snafu hat geschrieben:Aber gehört nicht genau das zu den "einfachen" Frames, von denen du vorher gesprochen hast und wo der Designer angeblich geeigneter wäre?

Ich meine damit eher das was sich zwischen Toolbar und Statusbar abspielt. Es gibt Programme mit einer mehr oder weniger statischen Oberfläche. Die hat man mit dem Designer sicher bequemer erstellt. Oder auch Dialoge lassen sich bequem erstellen.

Aber nehmen wir den Designer doch mal selber. Der besteht aus einem CentralWidget in dem man "designed" und rings herum Dock Widget deren Inhalt selbst meist aus wenigen Widgets besteht die zudem noch zur Laufzeit gefüllt werden. Wenn jetzt noch dazu kommt das die Editoren im CentralWidget oder die Dock Widgets Menus oder Toolbars einfügen ist man mit dem Designer schnell am Ende. Ist zumindest meine Meinung. Korrigiert mich sollte es nicht so sein.

Du meinst z.B. dass Editor X drei andere Symbole als Editor Y in die Toolbar einfügen soll, sobald er aufgerufen wird? Da würde ich persönlich eher mit dem Designer alle Symbole, die möglich sind, in die Toolbar einsetzen und anschließend die speziell auf einen bestimmten Editor ausgelegten Symbole im Konstruktor deines Programms ausblenden. Wenn ein bestimmter Editor dann seine "eigenen" Symbole benötigt, kann er sie mittels show() anzeigen. Mit vorher festgelegten Layouteigenschaften für deine Toolbar (was im Designer ein paar wenige Mausklicks bedeutet) hätte man auch keine Lücke, sondern er würde die Symbole in der Toolbar bei Bedarf verschieben. Du müsstest also nicht mal darauf achten, dass ein Symbol bei seiner Erstellung eventuell ein anderes Symbol überlappen könnte. Selbstverständlich ist das kein Designer-internes Hokuspokus, sondern es werden den Objekten auch nur Eigenschaften zugewiesen, die man genau so gut mit einem beliebigen Editor programmieren kann, wenn man denn möchte. Ich persönlich finde GUI-Programmierung aber eher nervig und kümmere mich lieber um die Logik des Programms als um die genaue Position der grafischen Elemente. "Position" ist hier natürlich nicht zu verwechseln mit "Anordnung". Denn die spielt ja schon eine wichtige Rolle.

Sicher, so könnte man es auch machen. Aber wie gesagt, es ist eigentlich müßig Argumente für oder gegen einen Designer auszutauschen weil jeder eigene Vorlieben und Vorstellungen hat.

snafu hat geschrieben:Ich persönlich finde GUI-Programmierung aber eher nervig und kümmere mich lieber um die Logik des Programms als um die genau Position irgendwelcher Elemente.

So denken leider viele weshalb viele GUI Tools, vor allem unter Linux, doch eher bescheiden sind und viele (zurecht) sagen das die Konsole besser ist. Eine durchdachte GUI macht halt Arbeit, egal ob man einen Designer verwendet oder nicht. Ich ärgere mich hier zb tagtäglich über eine (teure) Windows Software bei der die GUI auch nicht besonders gelungen ist worunter die Bedienung leidet. Sicher, man kann es nie allen recht machen, aber man kann es zumindest versuchen.

@snafu: Das ist aber nicht wirklich skalierbar. Um im Designer alle Symbole für mögliche Editoren in eine Toolbar zu stecken, müsste man ja schon wissen was die Editoren für Symbole haben. Nicht besonders flexibel. Dieses Wissen gehört in den einzelnen Editor, und nicht in die Haupt-GUI.

BlackJack hat geschrieben:@snafu: Das ist aber nicht wirklich skalierbar. Um im Designer alle Symbole für mögliche Editoren in eine Toolbar zu stecken, müsste man ja schon wissen was die Editoren für Symbole haben. Nicht besonders flexibel. Dieses Wissen gehört in den einzelnen Editor, und nicht in die Haupt-GUI.

Das sowieso. Und man weiß ja zum Design Zeitpunkt vielleicht nichtmal was noch alles dazukommt. So muss man halt jedes mal den Hauptframe anfassen um etwas zu ändern.

Als ich vor 3-4 Jahren noch unter Windows mit dem Visual Studio .NET rumhantiert hab wollte ich das auch immer so machen. Schön alles mit dem Designer zusammenklickern und in den Frame quetschen. Mittlerweile denke ich halt anders darüber