@Sirius3: der übliche Weg für callbacks sind bei anderen Gui Frameworks Signale. Hast du etwas dagegen, weil das global ist?
Signale ist dasselbe wie so ein callback Dictionary, nur noch erweitert. Es können sich da auch mehrere Empfänger für ein und dasselbe Signal registrieren, sodass dann beim Senden des Signals verschiedene Callbacks aufgerufen werden.
Das ist also etwas allgemein Übliches und nicht etwas, was man vermeiden sollte. Das Vermeiden geht bei anderen Gui Framworks eh nicht, weil es da nur über Signale geht.
Frame leeren / Klassenübergreifend
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
Das Dictionary {} wird nur einmal am Anfang zugewiesen: callbacks = {}Sirius3 hat geschrieben:@Alfons Mittelmeyer: dann nimmt man aber den Signal-Mechanismus des Frameworks, oder falls es das nicht gibt, schreibt man sich selbst einen. Aber man nimmt KEINE GLOBALEN VARIABLEN!
callbacks ist daher eine KONSTANTE.
@Alfons Mittelmeyer: Nein das ist keine Konstante. Konstanten haben einen Konstanten *Wert*. Und den Wert veränderst Du. Global.
Warum trollst Du schon wieder? Du weisst ganz genau dass das globaler Zustand ist. Entweder ist das Vorsatz oder Du weisst es nicht, dann wär's Dummheit. An Dummheit mag ich in diesem Fall nicht glauben, also stellt sich die Frage warum Du hier schon wieder mit diesem getrolle anfängst.
Warum trollst Du schon wieder? Du weisst ganz genau dass das globaler Zustand ist. Entweder ist das Vorsatz oder Du weisst es nicht, dann wär's Dummheit. An Dummheit mag ich in diesem Fall nicht glauben, also stellt sich die Frage warum Du hier schon wieder mit diesem getrolle anfängst.
- Schwarzer Wolf
- User
- Beiträge: 56
- Registriert: Donnerstag 5. Januar 2017, 05:24
Ich Grüße Euch.
Also ich hatte das mit einer extra Menüklasse gemacht und dann wieder verworfen. Ich zumindest fand es unübersichtlicher, als wenn es in der RootGui ist. Ich bin dabei, mir momentan sozusagen eine Gui Vorlage zu erstellen, sodass ich sie für andere Projekte mitbenutzen kann.
Alles funktioniert bisher so weit, und es ist viel Strukturierter als davor.
Was ist eigentlich der Unterschied wenn man die RootGui mit tk.Tk oder als tk.Frame aufruft?
Die RootGui sieht momentan folgendermaßen aus:
Also ich hatte das mit einer extra Menüklasse gemacht und dann wieder verworfen. Ich zumindest fand es unübersichtlicher, als wenn es in der RootGui ist. Ich bin dabei, mir momentan sozusagen eine Gui Vorlage zu erstellen, sodass ich sie für andere Projekte mitbenutzen kann.
Alles funktioniert bisher so weit, und es ist viel Strukturierter als davor.
Was ist eigentlich der Unterschied wenn man die RootGui mit tk.Tk oder als tk.Frame aufruft?
Die RootGui sieht momentan folgendermaßen aus:
Code: Alles auswählen
class RootGui(tk.Tk):
""" root gui of the program """
def __init__(self):
tk.Tk.__init__(self)
# classes
self.program_info = ProgramInfo()
self.license = License()
# config
self.attributes('-zoomed', True)
self.grid_columnconfigure(0, weight=1)
self['bg'] = '#000000'
self.title('{title} - {version}'.format(title=self.program_info.title,
version=self.program_info.version))
self.grid()
# menu bar
top = self.winfo_toplevel()
self.menubar = tk.Menu(top)
top['menu'] = self.menubar
self.menubar['bg'] = '#000000'
self.menubar['fg'] = '#ffffff'
self.menubar['font'] = ('Monospace', 10)
# submenu
self.file = tk.Menu(master=self.menubar)
self.about = tk.Menu(master=self.menubar)
# methods
self.submenu_cascades()
self.submenu_file()
self.submenu_about()
def clear(self):
""" removes the grids -> clear the screen """
self.license.grid_remove()
self.program_info.grid_remove()
def submenu_cascades(self):
""" cascades of the submenu """
self.menubar.add_cascade(label='Datei',
menu=self.file)
self.menubar.add_cascade(label='Über',
menu=self.about)
def submenu_file(self):
""" submenu of cascade file """
self.file.add_command(label='Beenden',
command=self.quit)
def submenu_about(self):
""" submenu of cascade about """
self.about.add_command(label='Lizenz',
command=self.submenu_about_license)
self.about.add_command(label='Programm',
command=self.submenu_about_program)
def submenu_about_license(self):
""" submenu_about -> 'Lizenz' """
self.clear()
self.license.grid()
self.license.gui()
def submenu_about_program(self):
"""submenu_about -> 'Programm' """
self.clear()
self.program_info.grid()
self.program_info.gui()
Wer in der Wildnis lebt, muss zum Wolf werden, oder als Schaf sterben.
(Syrisches Sprichwort)
(Syrisches Sprichwort)
-
- User
- Beiträge: 1715
- Registriert: Freitag 31. Juli 2015, 13:34
Möglich ist alles, aber üblich oder schön ist es nicht. Wenn Du mit einem anderen Gui Element startest, wird auch das Anwendungsfenster automatisch erzeugt, etwa:Schwarzer Wolf hat geschrieben:IWas ist eigentlich der Unterschied wenn man die RootGui mit tk.Tk oder als tk.Frame aufruft?
Code: Alles auswählen
import tkinter as tk
button = tk.Button(text="Button")
button.pack()
button.mainloop()
Ach so, wenn Du mit tk.Frame aufrufst, erzeugst Du einen Frame im Anwendungsfenster und dabei auch das Anwendungsfenster. Wenn Du mit tk.Tk aufrufst, erzeugst du den Frame nicht sondern arbeitest dann weiter im Anwendungsfenster. Üblich ist, zuerst das Anwendungsfenster zu erzeugen und dann auch den Frame zu erzeugen, sofern man diesen will.
Dagegen einen Frame zu erzeugen, den man dann nicht benutzt, wie Du es tatest, sollte man nicht tun.