Frame leeren / Klassenübergreifend

Fragen zu Tkinter.
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

@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.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@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!
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

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!
Das Dictionary {} wird nur einmal am Anfang zugewiesen: callbacks = {}

callbacks ist daher eine KONSTANTE.
Sirius3
User
Beiträge: 17711
Registriert: Sonntag 21. Oktober 2012, 17:20

@Alfons Mittelmeyer: lies doch in einem der anderen dreihundertsiebenunzwanzig Beiträge nach, wo man Dir schon globale Variablen abgewöhnen wollte, was globale Variablen sind. Das will ich hier nicht wiederholen.
BlackJack

@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.
Benutzeravatar
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. :P :P :P

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)
Alfons Mittelmeyer
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

Schwarzer Wolf hat geschrieben:IWas ist eigentlich der Unterschied wenn man die RootGui mit tk.Tk oder als tk.Frame aufruft?
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:

Code: Alles auswählen

import tkinter as tk
button = tk.Button(text="Button")
button.pack()
button.mainloop()
Mit button.winfo_toplevel() könnte man dann die root bekommen, aber sollte das sein?

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.
Antworten