tkinter funktion in label ausgeben

Fragen zu Tkinter.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@wuf: Das hier gesagte gilt auch für komplexere Anwendungen. Man teilt eine Klasse nicht einfach auf zwei auf die sich gegenseitig benötigen nur um in jeder davon weniger Methoden oder Attribute zu haben. Das muss schon irgendwie Sinn machen. Und man kann das an zu kleinen Beispielen wo es gar nichts aufzuteilen gibt, weder zeigen noch lernen wie man *sinnvoll* aufteilt, weil es hier eben nichts sinnvoll aufzuteilen gibt.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Benutzeravatar
wuf
User
Beiträge: 1529
Registriert: Sonntag 8. Juni 2003, 09:50

@__blackjack__: Ist mir alles klar. Wie sieht es dann beim Model View Controller. Da werden doch auch drei Klassen eingesetzt um ein komplexes Programm aufzuteilen. Natürlich ist diese simple Anwendung nicht ideal in diese MVC-Struktur zu integrieren. Ich habe sie aber trotzdem missbraucht um sie in diese MVC-Struktur anzupassen.

Hier mein Versuchsskript:

Code: Alles auswählen

import math
import random

import tkinter as tk

APP_TITLE = "MVC"

SAMPLING_TIME = 1000
E0 = 6.1078 # Sättigungsdampfdruck in hPa

class Model():
    
    def __init__(self):
        pass

    def taupunkt_berechnen(self, temp, hum):
        a = self.a_bestimmen(temp)
        b = self.b_bestimmen(temp)
        saettigungsdampfdruck = self.saettigungsdampfdruck_berechnen(a, b, temp)
        v = self.v_berechnen(hum, saettigungsdampfdruck)
        taupunkt = b*v/(a-v)
               
        return round(taupunkt, 2)

    def dampfdruck_berechnen(self, hum, saettigungsdampfdruck):
        dampfdruck = hum / 100 * saettigungsdampfdruck
        return dampfdruck

    def saettigungsdampfdruck_berechnen(self, a, b, temp):
        saettigungsdampfdruck = E0 * 10 ** ((a * temp) / (b + temp))
        return saettigungsdampfdruck

    def v_berechnen(self, hum, saettigungsdampfdruck):
        dampfdruck = self.dampfdruck_berechnen(hum, saettigungsdampfdruck)
        v = math.log10(dampfdruck/E0)
        return v

    def a_bestimmen(self, temp):
        if temp >= 0:
            a = 7.5
        else:
            a = 7.6
        return a

    def b_bestimmen(self, temp):
        if temp >= 0:
            b = 237.3
        else:
            b = 240.7
        return b

        
class Gui():
    # View
    LABEL_FONT = ("Helvetica", 40,"bold")
    LABEL_BG = "#00dbde"
    LABEL_FG = 'white'
    BUTTON_FONT = ("Helvetica", 12,"bold")
    
    def __init__(self, app):
        self.app = app
        
        self.main_frame = tk.Frame(self.app.main_win)
        self.main_frame.pack(fill='both', expand=True)
        
        self.temperature = tk.StringVar()
        self.humidity = tk.StringVar()
        self.taupunkt = tk.StringVar()

        data_display_frame = tk.Frame(self.main_frame)
        data_display_frame.pack(expand=True)

        tk.Label(data_display_frame, fg=self.LABEL_FG,
            background=self.LABEL_BG, textvariable=self.temperature, width=10,
            font=self.LABEL_FONT).pack(fill='x', pady=8)
            
        tk.Label(data_display_frame, fg=self.LABEL_FG,
            background=self.LABEL_BG, textvariable=self.humidity,
            font=self.LABEL_FONT).pack(fill='x', pady=8)
         
        tk.Label(data_display_frame, fg=self.LABEL_FG,
            background=self.LABEL_BG, textvariable=self.taupunkt,
            font=self.LABEL_FONT).pack(fill='x', pady=8)

        button_frame = tk.Frame(self.main_frame)
        button_frame.pack(side='bottom', pady=10)
        
        tk.Button(button_frame, text="Beenden", font=self.BUTTON_FONT,
            command=self.app.shutdown).pack()
        
    
class Application():
    # Controller
    def __init__(self, main_win):
        self.main_win = main_win
       
        self.model = Model()
        self.gui = Gui(self)
        self.sampling_loop()
        
    def sampling_loop(self):
        temperature = random.randrange(5.0, 28.0)
        humidity = random.randint(70, 90)
        taupunkt = self.model.taupunkt_berechnen(temperature, humidity)
                    
        self.gui.temperature.set("{0:0.1f} °C".format(temperature))
        self.gui.humidity.set("{:.0f} %".format(humidity))         
        self.gui.taupunkt.set("{0:0.1f} °C".format(taupunkt))
               
        self.main_win.after(SAMPLING_TIME, self.sampling_loop)

    def shutdown(self):
        print("Terminate app related items")
        self.main_win.withdraw()
        self.main_win.destroy()


def main():
    main_win = tk.Tk()
    main_win.title(APP_TITLE)
    main_win.attributes("-fullscreen", True)
    
    _app = Application(main_win)
    
    main_win.mainloop()
 
 
if __name__ == '__main__':
    main()      
Gruss wuf :-)
Take it easy Mates!
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Aaaaahhhrg. Vergiss MVC am besten. Ich habe echt noch nie etwas gutes gesehen wenn jemand versucht hat ”MVC” umzusetzen. Das gibt es ausserhalb von Rahmenwerken nicht wirklich und wenn man ein Rahmenwerk verwendet das eine Variante von MVC anbietet, dann sollte man auch genau diese Variante umsetzen die da angeboten/unterstützt wird.

Das ”Model” hat hier wieder das Problem was wir schon mal hatten: Das ist keine Klasse. Es macht wirklich keinen Sinn alles in Klassen zu stopfen und da jetzt mit Gewalt auch noch irgendein Entwurfsmuster umsetzen zu wollen macht noch weniger Sinn. Entwurfsmuster lösen Probleme, begehe bitte nicht den Fehler ein Entwurfsmuster zu nehmen und dafür ein Problem zu suchen/erfinden was es gar nicht gibt. MVC wird man auch in Rahmenwerken nicht einsetzen wenn man kein Problem lösen muss, für das dieses Muster da ist. Das heisst auch wenn das Rahmenwerk eine Form von MVC unterstützt, heisst das nicht, das man da dann anfängt jede GUI damit zu strukturieren, sondern nur Teile die das brauchen, sofern es die überhaupt gibt. Selbst bei einer umfangreichen GUI kann es also sein, das man da nirgends MVC braucht. Das ist keine magische Wunderwaffe – wie generell Entwurfsmuster das nicht sind.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Benutzeravatar
wuf
User
Beiträge: 1529
Registriert: Sonntag 8. Juni 2003, 09:50

Ok __blackjack__

Danke für deine Kommentare und Ansichten. Diese helfen mir aber nicht weiter. Im Gegenteil mein Fazit ist, dass ich es nur falsch machen kann. Die Leute die sich einmal mit MVC herumgeschlagen haben war auch nicht alles Idioten. Wenn du es nicht schon gemacht hast empfehle ich dir doch einmal ein Buch herauszugeben. Ein Buch, welches dem Leser einmal klar macht, dass Importe verziert mit Sternchen Böse sind. Sonst musst du dies in deine folgenden Kommentaren noch tausendfach wiederholen. Wünsche dir alles Gute einen schönen Tag und weiterhin viel Erfolg.

Gruss wuf :-)
Take it easy Mates!
Sirius3
User
Beiträge: 17741
Registriert: Sonntag 21. Oktober 2012, 17:20

Niemand hat behauptet, irgendwer wäre ein Idiot. Und theoretisch kann man sich schöne Modelle ausdenken, die oft auch beim Verstehen eines Problems helfen. Die Umsetzung soll aber mit minimalem Aufwand gut wartbaren Code ergeben. Weniger Code und weniger Abhängigkeiten.

Das C steht zwischen M und V, hat also viele Abhängigkeiten. Geschäftslogik ist besser im Modell aufgehoben, GUI-Steuerung besser im View und schon hat man meist nichts mehr, was der Controller tun kann, fällt also im realen Programmcode weg und man hat nur noch eine Trennung zwischen GUI und Logik.
Du versucht aber mit aller Gewalt unbedingt einen Controller zu implementieren, der aber keinen Gewinn bringt, sondern nur vieles komplizierter macht.

Bei komplexen GUIs mit 10000 Zeilen hat man normalerweise auch nicht die eine GUI-Gott-Klasse, sondern spaltet sie in viele, möglichst unabhängige, spezialisierte Views auf. Vielleicht hat es dann auch wieder einen Platz für einen Controller, das kommt aber auf das konkrete Projekt an.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@wuf: Die Leute haben sich nie mit MVC oder einem anderen Entwurfsmuster herumgeschlagen sondern haben reale Probleme gelöst. Und irgendwann wurde festgestellt das mehrere Programmierer(teams) ein Problem auf die gleiche Art gelöst haben, und dass diese Art und Weise Sinn macht. Und dann wurde diesem Muster ein Name gegeben. Entwurfsmuster werden nicht *er*funden, sondern *ge*funden. In vorhandenem Code. Und ein Muster muss bevor es gefunden werden kann, auch mehrfach verwendet worden sein, denn sonst ist es kein Muster.

Mit MVC schlagen sich nur Leute herum die es falsch herum angehen – die sagen ich habe hier ein Entwurfsmuster und suche dafür jetzt ein Problem. So funktioniert das aber nicht. Man hat erst ein Problem und dann gibt es vielleicht ein Entwurfsmuster was beim Lösen hilft. Zu einem Entwurfsmuster gehört immer eine Beschreibung eines *konkreten* Problems, das mit diesem Muster gelöst werden kann. Und mindestens zwei reale Projekte wo man sich die Umsetzung des Musters mal anschauen kann.

MVC kann man IMHO tatsächlich nur falsch machen, denn es ist überhaupt nicht so wirklich klar was MVC überhaupt ist. Frag 5 Programmierer und Du bekommst 10 unterschiedliche Antworten. Mindestens. Es ist nicht einmal unstrittig ob das überhaupt ein Entwurfsmuster ist, oder nicht eine Sammlung von anderen Entwurfsmustern, und wenn ja welche (und welche nicht). Das Vorhaben „ich will jetzt MVC implementieren“, und das dann auch noch als reiner Selbstzweck, kann also nur scheitern. Das ist schlicht Zeitverschwendung.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Antworten