__deets__ hat geschrieben:Du bist doch derjenige der hier von riesigen Hierarchien redet, die dann unwartbar werden. Der gezeigte Code hier faellt offensichtlich nicht unter diese Kategorie.
Bei diesem Code habe ich noch eine Kleinigkeit vergessen, mämlich dass da noch eine Message im Labelframe definiert war. Ja macht ja nichts. Im Original DynTkInter Script sieht er so aus, aber nur der von Modules.py also ohne Toplevel und Menu:
Code: Alles auswählen
Frame('Toolbar',**{'link': 'guidesigner/Toolbar.py'})
Frame('GuiFrame',**{'link': 'guidesigner/GuiFrame.py'})
LabelFrame('WidgetPath',**{'text': ' Path: ','labelanchor' : 'w','bd' : 0})
goIn()
Message('message_path',**{'bg': '#ffffa0','anchor': 'nw'})
pack(anchor='w', fill='x', expand=1)
### CODE ===================================================
# ...
### ========================================================
goOut()
widget('Toolbar').pack(fill='x')
widget('WidgetPath').pack(anchor='w', fill='x')
widget('GuiFrame').pack(anchor='nw')
Den Code habe ich hier mal nicht mit gepostet, war eh nur die Ausgabe des Widget Pfades in dem gelben Streifen oben.
Programmierung innerhalb solchen Scripts benutzt wahrscheinlich außer mir niemand und will wahrscheinlich auch niemand. Aber XML habe ich gehört, hätte man gerne. Ich habe auch schon darüber nachgedacht, ob auf Pygubu Art oder ob man qt Kompatibilität erreichen könnte. Wahrscheinlich nicht ganz. Man könnte ja mal Pygubu XML versuchen und danach mit den Erfahrungen daraus an qt Kompatibilität denken.
Im Prinzip ist das von der Struktur so aufgebaut wie ein XML File, nur dass es ausführbarer Python Code ist. Und dann gibt es noch zwei spezielle Properties: 'link' heißt, auch das folgende GUI Script wird nachladen. Und ### CODE heißt, dass das ein nicht generierter Code ist, den der Programmierer dazu geschrieben hat, sozusagen eine property Code. Dieser Code wird bei normalem Start ausgeführt. Wenn das Modul im GUI Designer geladen wird, wird der Code je nach Art des Ladens nicht ausgeführt oder ausgeführt. Beim Laden im GUI Designer wird dieser Code aber als Property mitgeladen und beim Abspeichern auch wieder mit abgespeichert und kann in einem Text Widget editiert und gar zur Laufzeit ausgeführt werden. Naja, ich schreibe nur manchmal einen Kommentar rein, wenn ich im Menü etwas ändern will. Das habe ich nämlich nicht unterteilt und kann dann im Programmeditor die Stelle des betreffenden Codes leicht finden, indem ich dann nach dem Kommentar suche.
Wenn man dieses Modul ausführt, erhält man die statische GUI des GUI Designers mit Ausnahme einiger Widgets, die kein Layout haben:
Und wenn man das exportiert und mit dem Modul builder sich die IDs der Widgets ausgeben läßt, sind es 212 Widgets. Exportierter reiner GUI Code ergibt das ein GUI File von 966 Zeilen. Das Menü ist da nicht dabei.
Jetzt verstehe ich nicht, warum das jetzt wieder nichts Komplexes sein sollte. Und es macht überhaupt keinen Unterschied, ob eine GUI von der Source her in ganz kleine überschaubare Zeile zerteilt ist. Das ist gut, damit man sich gut zurechtfindet. Trotzdem erhält man mit builder.py die IDs der kompletten GUI. Denn trotz Zerteilung in der Source wie auch immer, es gibt nur eine GUI und das ist die tkinter GUI.
__deets__ hat geschrieben:
Meine Antworten wenden sich meistens gegen von dir getaetigte Aussagen, Tools wie pygubu oder die Verwendung von nicht-code basierten Formaten wie XML und JSON zur Erstellung von GUIs waeren unbrauchbar weil nicht profesionell. Das entspricht nicht den Erfahrungen die ich persoenlich mit einer grossen, von Millionen Usern benutzen Anwendung, und viele andere hier und da draussen in der Welt gemacht haben.
Habe ich etwas von unprofessionell geschrieben? Kann ich mich nicht daran erinnern. IDs sind nichts Schlechtes. Es kommt aber darauf an, wie sie eingesetzt werden. Für einen guten Programmierer sind solche IDs kein Problem, denn er weiß, dass man nicht kreuz und quer auf alles zugreifen soll. Er implementiert wohl definierte Interfaces. Er benutzt auch Message Interfaces.
Ganz schlecht: über Ebenen hangeln. Von einem Submenü über die Root bis irgendwo in eine tiefe GUI Ebene
Besser: IDs benutzen
Noch besser: dabei wohl definierte Interfaces benutzen
Am Besten: Message Interfaces benutzen
Und ich weiß aus kürzlich gemachter Erfahrung, dass jemand der angefangen hat sich in Python und GUI einzuarbeiten und eine kompexe GUI implementieren möchte, am Besten fährt, wenn man ihm keine IDs zur Verfügung stellt, mit denen er kreuz und quer auf alles zugreifen kann. Wenn man die Anfänge gesehen hat, denkt man Null Chance, dass der eine komplexe GUI fertig bringt. Man überzeugt ihn, dass es keine gute Idee ist, sich von Menüs irgendwo in die GUI zu hangeln und schlägt ihm den Eventbroker vor. Der dabei benützte Eventbroker gibt auch Meldungen aus, nämlich, dass der Empfänger noch nicht existiert und dazu auch die Message. Und dann kann man sich freuen, weil man sieht, dass eine Komponente schon tut und fertig ist. Lediglich der Empfänger ist noch nicht implementiert. Bei Methodenaufruf, müßten diese schon existieren und man müßte auch wissen wo. Bei Messages muß man sich darum nicht kümmern sondern nur die Message senden.
__deets__ hat geschrieben:
Wenn du ein Beispiel fuer eine grosse Qt-Anwendung sehen willst, die recht offensichtlich ihre hochkomplexe UI in viele, viele, viele kleinere , handhabbare Stuecke zergliedert, kann ich nur empfehlen einen Blick auf LibreCAD/QTCAD zu werfen:
https://github.com/LibreCAD/LibreCAD/tr ... c/ui/forms
Die groesste UI-Datei darin ist qg_dlgtext.ui mit ~60KB ist nur *ein* Dialog - zum einstellen der Fonteigenschaften. Mit vielleicht 50 oder so Widgets, Struktur/Layout-Elemente inbegriffen.
Insofern bleibe ich dabei: man dekompositioniert Anwendungen in kleine, ueberschaubare Eigenheiten. Das die Gesamthierarchie dann gross wird - geschenkt.
Ich stimme mit Dir da völlig überein. Ich habe auch gesehen, dass auch unerfahrene Programmierer dann das gerne tun, wenn sie sehen, dass das auch ganz ohne Probleme geht. Nur in den Modulen den Eventbroker importieren und dann kann gesendet und empfangen werden, ohne dass etwas anders wäre. Und der Code ist dann in kleine überschaubare Einheiten zerteilt. Und man zerteilt auch die GUI weil man dann besser sieht, welcher GUI Teil zu welchem Code gehört.
Also IDs sind wirklich nichts Schlechtes, aber in den Händen eines unerfahrenen Programmierers führen sie leicht zu nicht mehr durchschaubarem Code, weil dieser dann nicht an wohl definierte Interfaces denkt, wenn er ganz einfach quer Beet auf alle Widgets zugreifen kann.