Erben von tk.Tk

Fragen zu Tkinter.
Antworten
Üpsilon
User
Beiträge: 222
Registriert: Samstag 15. September 2012, 19:23

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
User
Beiträge: 222
Registriert: Samstag 15. September 2012, 19:23

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?
PS: Die angebotene Summe ist beachtlich.
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

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

Üpsilon hat geschrieben: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
User
Beiträge: 1715
Registriert: Freitag 31. Juli 2015, 13:34

Üpsilon hat geschrieben: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
Antworten