Seite 1 von 1

Erben von tk.Tk

Verfasst: Sonntag 30. Juli 2017, 14:54
von Ü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 :)

Re: Erben von tk.Tk

Verfasst: Sonntag 30. Juli 2017, 15:09
von BlackJack
@Üpsilon: Ist das tatsächlich so verbreitet?

Re: Erben von tk.Tk

Verfasst: Sonntag 30. Juli 2017, 20:15
von Ü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?

Re: Erben von tk.Tk

Verfasst: Sonntag 30. Juli 2017, 20:25
von 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.

Re: Erben von tk.Tk

Verfasst: Sonntag 30. Juli 2017, 23:37
von Alfons Mittelmeyer
Ü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?

Re: Erben von tk.Tk

Verfasst: Montag 31. Juli 2017, 00:24
von Alfons Mittelmeyer
Ü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