Grüß euch,
ich programmiere ein Interface mit einem Einkaufswagen und einer Produktseite. Jeweils ein TopLevel.
Auf der Produktseite habe ich einen Knopf, ("Quasi zum Einkaufswagen hinzufügen") und möchte auf Knopfdruck mein Produkt (=ein Label) in das TopLevel des Einkaufswagens kopieren.
Das Einkaufswagen TopLevel ist zu diesem Zeitpunkt aber noch nicht geöffnet, ich wähle ja erst mein Produkt aus und füg es hinzu und irgendwann wenn ich fertig bin mit auswählen geh ich in den Einkaufswagen und öffne dieses TopLevel.
Nun ist die Frage, wie löst man sowas... Speziell das grid() im Einkaufswagen TopLevel, das Produkt das ich hinzufüge ist ja nicht immer an derselben Stelle im Einkaufswagen (=vielleicht kommt ja noch ein anderes Produkt vorher, dann muss das Produkt eine Zeile runter rutschen).
Meine Idee wäre gewesen eine Liste zu erstellen, zu dieser Liste mittels .append() meine Produkte hinzuzufügen und dann die Liste im Rahmen eines Labels im EInkaufswagen wieder anzeigen zu lassen, klingt aber ultra falsch in meinen Ohren. Und bin mir auch nicht sicher ob dann noch .pop() funktionieren würden, sprich um ein Produkt aus dem Einkaufswagen zu entfernen.
Danke und mit freundlichen Grüßen
TopLevel
Bei GUIs gibt es das Model-View-Konzept. Das bedeutet, dass man die Datenhaltung (Einkaufswagen) von der Darstellung (grid) trennt. Die gesamte Geschäftslogik, also Produkte in Einkaufswagen legen, löschen, sortieren, kaufen, wird so implementiert, dass sie ohne GUI komplett nutzbar ist, da die Art der Nutzung sich ja auch ändern kann, bzw. es verschiedene Arten der Nutzung geben kann (Textbasiert, GUI, Web, ...), und der wichtigste Grund: weil man auch alle Aktionen per Unit-Tests testen können muß.
Auf diese Model setzt dann das View auf, also die GUI, die nur den Inhalt des Einkaufswagens darstellen können muß, bzw. updaten können muß.
Auf diese Model setzt dann das View auf, also die GUI, die nur den Inhalt des Einkaufswagens darstellen können muß, bzw. updaten können muß.
Ich wuerde sogar so weit gehen zu sagen, dass tkinter in dieser Beziehung so weit hintendran ist, dass es fuer mich fuer eine solche GUI nicht in Frage kaeme. Wenn es lizenztechnisch vereinbar ist mit dem Projekt, wuerde ich zu Qt/PyQt oder PySide raten. Das beherrscht MVC Muster ziemlich gut.
Ich bedanke mich für deine Antwort. Letzten Endes ist das "Projekt" nur für mich selber und zum üben von tkinter. Dementsprechend versuche ich das in Tkinter auch einzubauen und werde nicht wechseln. mfg TE__deets__ hat geschrieben: ↑Freitag 29. April 2022, 11:26 Ich wuerde sogar so weit gehen zu sagen, dass tkinter in dieser Beziehung so weit hintendran ist, dass es fuer mich fuer eine solche GUI nicht in Frage kaeme. Wenn es lizenztechnisch vereinbar ist mit dem Projekt, wuerde ich zu Qt/PyQt oder PySide raten. Das beherrscht MVC Muster ziemlich gut.
Das klingt vielversprechend, aber wohl noch etwas kompliziert für meinen Kenntnisstand ^^ ich bedanke mich für deine AntwortSirius3 hat geschrieben: ↑Freitag 29. April 2022, 10:55 Bei GUIs gibt es das Model-View-Konzept. Das bedeutet, dass man die Datenhaltung (Einkaufswagen) von der Darstellung (grid) trennt. Die gesamte Geschäftslogik, also Produkte in Einkaufswagen legen, löschen, sortieren, kaufen, wird so implementiert, dass sie ohne GUI komplett nutzbar ist, da die Art der Nutzung sich ja auch ändern kann, bzw. es verschiedene Arten der Nutzung geben kann (Textbasiert, GUI, Web, ...), und der wichtigste Grund: weil man auch alle Aktionen per Unit-Tests testen können muß.
Auf diese Model setzt dann das View auf, also die GUI, die nur den Inhalt des Einkaufswagens darstellen können muß, bzw. updaten können muß.
mal sehen was sich da machen lässtDas kommt mir immer ein bisschen paradox vor. Einerseits will ich Oberfläche und Inhalt ordentlich auseinanderhalten. Andererseits soll mir mein GUI nicht nur die Oberfläche herstellen, sondern auch Modell-Klassen für die Daten liefern. Das lässt sich dann ja auch nur schwer wieder zerlegen, wenn ich die Oberfläche wirklich austauschen will.__deets__ hat geschrieben: ↑Freitag 29. April 2022, 11:26 Ich wuerde sogar so weit gehen zu sagen, dass tkinter in dieser Beziehung so weit hintendran ist, dass es fuer mich fuer eine solche GUI nicht in Frage kaeme. Wenn es lizenztechnisch vereinbar ist mit dem Projekt, wuerde ich zu Qt/PyQt oder PySide raten. Das beherrscht MVC Muster ziemlich gut.
Irgendwo muss man mal aus der Abstraktion ins Konkrete kommen. Und diese Schicht aus Klebstoff kann man nun wahlweise komplett selbst schreiben muessen, so wie in tkinter, oder man bekommt Abstraktionen wie die AbstractitemModels von Qt, die einem das deutlich erleichtern.bb1898 hat geschrieben: ↑Sonntag 1. Mai 2022, 21:21 Das kommt mir immer ein bisschen paradox vor. Einerseits will ich Oberfläche und Inhalt ordentlich auseinanderhalten. Andererseits soll mir mein GUI nicht nur die Oberfläche herstellen, sondern auch Modell-Klassen für die Daten liefern. Das lässt sich dann ja auch nur schwer wieder zerlegen, wenn ich die Oberfläche wirklich austauschen will.
Das man die Oberflaeche einfach austauschen koennte, ist auch einfach nicht realistisch. Man kann gute Domaenen-Modelle haben, die keinen GUI-Framework-spezifischen Code haben. Wobei die Qt Meta-Objekte und deren Signal/Slot-Verbindungen ein recht gutes Muster sind, um auch das zu machen. Aber GUI-Entwicklung ist immer im Detail tief an das Verhalten des konkreten Toolkits geknupeft. Und das ist signifikant viel Code, den wegzuschmeissen man nicht ohne Not macht. Darauf hin zu planen ist einfach nur ziemlich verschwendet, ausser man hat schon gleich zu Beginn klare Szenarien, in denen das Modell ohne GUI , oder mit einer ganz anderen, genutzt werden muss.
In tkinter ist es in meinen Augen mit mehr Arbeit verbunden, das zu tun. Weil es eben keine guten Abstraktionen dafuer gibt. Die musst du erst schaffen, und kannst dich dabei auch verheben. In Qt ist das mehr vorgegeben, und dazu gibt's Dokumentation etc. Aus meiner Sicht also etwas fraglich diese Entscheidung.