GUI Designer mit Source File update?

[Alfons Mittelmeyer]

Auch verstehe ich diese Anmerkung nicht: "buttons are dynamically created, so the widgets shall not be saved. Only the code, which creates them shall be saved" - was meinst Du hier mit dynamisch?

Die Anmerkung verstehst DFu auch nicht ganz. Sie bezieht sich auf eine Besonderheit der GUI Scripts. Markierte Source Code Teile werden, wenn man ein Script mit dem GUI Designer lädt, auch mit als Source Code geladen und beim Speichern wieder mitgespeichert.

Der Ausdruck besagt, dass hier der Sourcecode gespeichert werden soll, aber die Widgets für diesen Container nicht. Man will ja nicht dynamisch erzeugte Widgets nochmals zusätzlich als statische Widgets speichern.

Diese Funktion sollte man für den Export auch haben, denke ich, allerdings der Name paßt dann nicht ganz. Sollte man wohl umbennen. Das wäre, wenn ein Container nur dynamisch erzeugte Widgets hätte. Was allerdings bei einer Mischung von statisch und und dynamisch erzeugten Widgets sein sollte, darüber habe ich noch nicht nachgedacht. Man kann natürlich den Container markieren, dass die Widgets nicht gespeichert werden, aber die Definition der statischen Widgets durch eine Leerzeile von der __init__ trennen, damit sie erhalten bleiben.

Und wenn man sie doch mal editieren will, kann man zwischendurch mal die Erzeugung der dynamischen Widgets unterdrücken und die Sperre wieder herausnehmen oder auch die doppelten Widgets wieder löschen.

Also die Sperrfunktion sollte ich noch machen. Die saveOnlyCode speicher die Widgets nicht und Lock sorgt dafür, dass man den Container gar nicht mal betreten kann im GuiDesigner. Als Methode ist sie jetzt nicht implementiert, aber mit .isLocked = True, kann man jetzt auch den Container sperren und es wird dann auch keine Klasse für den Container erzeugt und man kann dann auch nicht in den Container mit dem GuiDesigner hinein. Sperren geht also doch schon.

[Alfons Mittelmeyer]

Also, das mit JSON Format ist nun auch ziemlich klar. Ich halte mich einfach an die ursprüngliche Syntax und beseitige Python spezifisches. Und für jede Zeile eine Liste:

Code: Alles auswählen

# Aus
Radiobutton('button_one',**{'text': 'One', 'underline': '0', 'anchor': 'w'}).grid(**{'sticky': 'ew', 'row': '1'})

# wird
['Radiobutton',['button_one',{'text': 'One', 'underline': '0', 'anchor': 'w'}],['grid',{'sticky': 'ew', 'row': '1'}]]

Da brauche ich auch nicht zu parsen, sondern kann es direkt umsetzen.
Nö noch einfacher:

Code: Alles auswählen

['Radiobutton','button_one',{'text': 'One', 'underline': '0', 'anchor': 'w'}],
['grid',{'sticky': 'ew', 'row': '1'}]

Und was braucht man zur Umsetzung?

- Einen Dictionary Eintrag mit Referenz auf die Funktion und Anzahl und Art der Parameter
- Als Art genügt dann True oder False, ob es ein Dictionary ist, denn da muss man dann ** dazumachen.
- und dann braucht man noch das automatische goOut() am Ende einer Children Liste.

Ach so, geht Referenz auf Klasse? Muss ich ausprobieren.

Ach was goIn() und goOut() ist?

Eine Selection hat zwei Komponenten:

- container
- widget

goIn() ist:

container = widget (aber nur bei Container Widgets)

goOut() ist:

widget = container
container = container.master

natürlich noch unter Berücksichtigung der root. Da bleibt der container auf der root stehen, denn weiter hinaus geht es nicht.

Also, angenommen, der ausgewählte Gegenstand wäre ein Schrank. goIn() bedeutet, der Schrank ist ausgewählt aber von innen mit Sicht auf die darin befindlichen Kleidungsstücke. Und goOut() bedeutet, der Schrank ist ausgewählt aber von außen mit Sicht auf das Zimmer, in dem er sich befindet. Würde man ein Kleidungsstück im Schrank auswählen, dann würde goOut() auch dazu führen. dass der Schrank danach von außen ausgewählt ist, entspricht in etwa cd .. aber gekoppelt mit Selektion