Sirius3 hat geschrieben:@Alfons Mittelmeyer: Python-Code zu generieren und diesen wieder versuchen zu parsen, um ihn weiter zu verarbeiten, ist nicht robust, vor allem nicht, wenn da noch jemand drin rumeditiert. Willst Du raten, was jetzt zur GUI gehört und was nicht? Und was meinst Du mit Queue? Das sicherste, beste und einfachste ist die GUI in einem geeigneten Dateiformat zu speichern, zu bearbeiten und im Programmcode zu laden.
Also Code parsen, tue ich nicht. Das sollt man wirklich vermeiden. Aber spezielle Markierungen am Code kann man bearbeiten, etwa:
Code: Alles auswählen
### NAME Cancel
Cancel = Button(parent,text="""Quit""")
Cancel.grid(column='2',sticky='e',row='3')
Das wäre reiner tkinter code. Gut für eigene kleine Programme oder Programmbeispiele in einem Script. Ein Zugriff von außen, nachdem die GUI aufgebaut ist, ist aber nicht möglich. Diese Kommentarzeile '### NAME Cancel' kann ich jederzeit finden, ohne zu parsen und kann sie ersetzten etwa durch: gui.preset_name('Cancel'). Wenn ich dabei eine spezielle library verwende mit modifiziertem Button Befehl, kann dann dieser Buttonbefehl den zuvor gesetzten Namen übernehmen, sodass dann über diesen Namen der Zugriff auf das Widget auch später noch möglich ist. Wenn ich gleich 'gui.preset_name('Cancel')' im Source Code hätte, würde manchem nicht gefallen, weil er dazu noch eine spezielle Library braucht, und er nur normales tkinter ohne späteren Zugriff will. Durch solche speziellen Kommentare braucht man keine verschiedenen Source Versionen für unterschiedliche Zwecke oder Umgebungen. Dieser Kommentar würde auch erlauben, dass der GUI Designer den richtigen Namen für das Widget bekommt, wenn man mit ihm etwa die GUI editiert und dabei diese Source verwendet anstelle einer getrennten gespeicherten Source in einem anderen Format.
Also parsen ist so etwas wohl nicht. Und warum soll nicht jemand darin rumeditieren? Warum soll man nicht Widgets auch ohne den GUI Designer hinzufügen können. Ich finde es praktisch, wenn man darin rumeditieren kann, wie man will. Für DynTkInter gibt es auch die Möglichkeit, zusätzlichen Code mit hineinzuschreiben und ihn entsprechend zu markieren, sodass er etwa im GUI Designer nicht ausgeführt wird oder wieder mit abgespeichert wird. Das ist auch im tkinter Format möglich, nur wenn man dann mit dem GUI Designer in Module splittet, würden die Einrückungen nicht mehr passen. Hier ein Beispiel:
Code: Alles auswählen
def main(parent):
### NAME myframe
myframe = Frame(parent)
def main(parent):
### NAME mybutton
mybutton = Button(parent)
mybutton.pack()
### CODE ===============
# hier etwa Callback definieren
### ======================
main(myframe)
myframe.pack()
# hier etwa weitere Widgets
### CODE ==============
# hier Code zum ersten Parent
### ====================
Hier sucht man nach '### CODE #' und schneidet dann die Zeilen einschließlich '### =' aus und speichert diese Abschnitte in einer Queue. Außerdem ersetzt man dann diese Code Blöcke, etwa durch 'gui.remember_code()', etwa so:
Code: Alles auswählen
def main(parent):
gui.preset_name('myframe')
myframe = Frame(parent)
def main(parent):
gui.preset_name('mybutton')
mybutton = Button(parent)
mybutton.pack()
gui.remember_code(parent)
main(myframe)
myframe.pack()
# hier etwa weitere Widgets
gui.remember_code(parent)
Das 'gui.remember_code' holt sich an der betreffenden Stelle den Code Abschnitt aus der Queue und übergibt ihn zum Merken an den jeweiligen Parent. Später kann dann die modifizierte GUI (Widget Definitionen) mitsamt dem gemerkten Code wieder so abgespeichert werden. Normalerweise könnte man auch die Einrückungen beim Splitten richtig behandeln, aber es gibt da auch diese Strings mit """. Und wenn man das dann richtig berücksichtigen wollte, dann müßte man doch ein klein wenig parsen. Soll ich, oder soll ich nicht, ist die Frage?
.
