Erben von tk.Tk

[Üpsilon]

Wieso ist es so verbreitet, eine Klasse Anwendung zu haben, die von tk.Tk erbt? Welchen Mehrwert hat das gegenüber der Variante, dass Objekte der Klasse Anwendung ein Attribut fenster halten, das ein tk.Tk ist?

Grüße

[BlackJack]

@Üpsilon: Ist das tatsächlich so verbreitet?

[Üpsilon]

Nun, es ist auf jeden Fall eine nicht komplett unübliche Variante, ein Tkinter-Programm zu schreiben.

Hier zuletzt gesichtet: viewtopic.php?f=18&t=40957#p312734

Frage bleibt: Welchen Vorteil hat die Vererbung hier gegenüber dem Halten als Attribut?

[kbr]

@Üpsilon: das ist die Frage nach "is a" oder "has a". Wenn Du Methoden überladen oder hinzufügen musst, dann kommt nur die erste Variante in Frage. Ansonsten bevorzuge ich die zweite.

[Alfons Mittelmeyer]

Wieso ist es so verbreitet, eine Klasse Anwendung zu haben, die von tk.Tk erbt? Welchen Mehrwert hat das gegenüber der Variante, dass Objekte der Klasse Anwendung ein Attribut fenster halten, das ein tk.Tk ist?

Grüße

Es ist einfach so, dass man aus einer GUI keinen globalen Wust machen sollte, sondern die übersichtlich gliedern sollte, also für jedes Container Widget eine Klasse. Warum sollte man da dann bei der Applikationsklasse eine Ausnahme machen, nur weil es die Applikationsklasse ist?

[Alfons Mittelmeyer]

Wieso ist es so verbreitet, eine Klasse Anwendung zu haben, die von tk.Tk erbt? Welchen Mehrwert hat das gegenüber der Variante, dass Objekte der Klasse Anwendung ein Attribut fenster halten, das ein tk.Tk ist?

Grüße

Also man kann auch völlig nicht verbreiteten Code schreiben.

Das ist zum Beispiel verbreiteter Code:

example.py

Code: Alles auswählen

# -*- coding: utf-8 -*-

try:
    import tkinter as tk
except ImportError:
    import Tkinter as tk

class Application(tk.Tk):

    def __init__(self,**kwargs):
        tk.Tk.__init__(self,**kwargs)
        self.minsize(260, 125)
        # widget definitions ===================================
        self.entry = tk.Entry(self)
        self.entry.place(y='24', x='67')
        self.label = tk.Label(self,text='label')
        self.label.place(y='24', x='8')
        self.button = tk.Button(self,text='button')
        self.button.place(y='69', x='161')

if __name__ == '__main__':
    Application().mainloop()

Ich schreibe das aber oft gerne so, ganz ohne Klassen und ohne Variablen bzw. Attribute und statt master einen String als Namen:

mycode.py

Code: Alles auswählen

config(**{'minsize': '260 125'})

Entry('entry').place(y='24', x='67')
Label('label',**{'text': 'label'}).place(y='24', x='8')
Button('button',**{'text': 'button'}).place(y='69', x='161')

Damit das aber geht, habe ich mir eine tkinter Erweiterung namens DynTkInter geschrieben, damit kann ich dann diesen Code ausführen.

Code: Alles auswählen

import DynTkInter as tk
tk.Tk().mainloop('mycode.py')

Aber dieser Code gefällt keinem hier im Forum. Deshalb schreibe ich dann bei mycode.py noch eine Zeile am Schluss dazu:

Code: Alles auswählen

config(**{'minsize': '260 125'})

Entry('entry').place(y='24', x='67')
Label('label',**{'text': 'label'}).place(y='24', x='8')
Button('button',**{'text': 'button'}).place(y='69', x='161')

exportApplication('example.py')

Und das macht dann daraus das example.py - siehe erstes Beispiel - und keiner regt sich mehr über meinen Code auf