Lässt sich der Verweis auf eine Variable abspeichern?

[Warhead]

...
Abhängige Zellen in einer Tabellenkalkulation könnten so ein Szenario sein.
...

Mhm, da bei TKs jedoch hinter einer "Zelle" i.d.R mehr Informationen als nur der reine Wert abgelegt wird, würde ich gerade "deswegen" hier von der pragmatischen Seite her an das Problem herangehen und es mittels Klassen lösen.

[BlackJack]

@Warhead: Verstehe das Argument gegen "cells" an der Stelle nicht? Die Klassen, die die Tabellenzellen modellieren kennen dann halt auch das zugehörige `cell`-Objekt.

[Warhead]

@BlackJack: Eine explizite Ablehnung der Verwendung von "cells" habe ich auch nicht geäussert. Ich bezog mich lediglich auf das von Leonidas vorgeschlagene "mir nicht vorstellebare Szenario (s.Post dafor)" von Zellen-Referenzen in einer Tabellenkalkulation.

[DaMutz]

ich weiss ja nicht welches GUI Framework du verwendest. Gibt es aber nicht die Möglichkeit jeden Tag als einzelnes Widget zu modelieren und dann könntest du doch jeden Tag absolut positionieren und jedes Item an diesem Tag wäre auf dem Widget auch absolute aber global gesehen relativ (kompliziert)

Oder du veränderst für jeden Tag der Nullpunkt der Positionierung um dann die Elemente an diesem Tag relative zur Ecke zu platzieren.

[mutetella]

ich weiss ja nicht welches GUI Framework du verwendest.

wxPython

Gibt es aber nicht die Möglichkeit jeden Tag als einzelnes Widget zu modelieren und ...

Anfangs hatte ich das so gelöst, jeder Tag war ein Panel in einem GridSizer... Dass das aber früher oder später (nicht nur wegen der Performance) im Wahnsinn endet, war mir bald klar...
Ich ging dann dazu über, jeden Tag als Instanz der Klasse Day() darzustellen. Allerdings hatte ich auch damit bald Performance-Probleme, wenn beim Navigieren über die Monate ständig unzählige getter und setter stattfinden.
Inzwischen gibt es lediglich noch die Klasse View(), die alle Elemente einer Kalenderansicht, genauer gesagt die Koordinaten und Texte, in Dictionaries ablegt und aus diesen heraus zeichnet.

Ich wäre aber schon daran interessiert, wie Du das mit einem Widget (welches Art) modellieren würdest.

Oder du veränderst für jeden Tag der Nullpunkt der Positionierung ...

Könntest Du mir das näher erklären?

Gruß
mutetella

[BlackJack]

@mutetella: Was zeigst Du denn da an? Ich kann mir kaum vorstellen, dass ein Monat mit maximal 31 Widgets für die Tage schon Performanceprobleme mit sich bringt!?

[mutetella]

@BlackJack:
Nun ja, wenn die Tage blöd liegen hast Du auch mal eine Kalenderansicht, die 42 Widgets beinhaltet. Auf diesen Widgets liegen dann noch weitere Widgets für Termineinträge und sonstiges Zeugs. Da ist ein wirklich flüssiges 'durchklicken' der Monate kaum noch drin. Fühlt sich dann an wie Sunbird... Jedenfalls kein Vergleich dazu, 42 Rechtecke mit den enthaltenen Texten und evtl. Kategoriebildchen zu zeichnen.

Was hast Du eigentlich damit gemeint, die Koordinaten als Objekte darzustellen?

Gruß
mutetella

[BlackJack]

@mutetella: Nicht die Koordinaten sondern die Daten, die Du da in Listen zusammenfasst.

[mutetella]

@BlackJack:
Meinst Du sowas in der Art:

Code: Alles auswählen

class Item():
    def __init__(self, x, y, w, h):
        self.x, self.y, self.w, self.h = x, y, w, h
        
    def get_item_coords_itself(self):
        return (self.x, self.y, self.w, self.h)

    def get_item_coords_header(self):
        return (self.x + 5, self.y + 5)

Gruß
mutetella

[DaMutz]

Da ich leider nur PyQt und nicht wxPython kenne beschreibe ich es wie ich es damit machen würde. Wahrscheinlich geht dies alles auch mit wxPython.
Jeder Tag ist ein Widget auf dem ein vertikales Layout ist und du für jeden Eintrag ein Label hinzufügst. Die Klasse Days erbt von Widget. Bei der Initialisierung gibts du ein Objekt auf das Model mit, damit der Tag seine Einträge kennt. Jeder dieser Tage kannst du jetzt einem GridLayout hinzufügen. Damit hätte wir einmal einen einfach ersten Kalender. Bis jetzt sehe ich nicht was langsam sein sollte auch bei 42 Tage. Das sind doch 42 Tage à 10 Einträge, denn mehr kann man ja eh nicht darstellen und diese 420 Einträge sollten doch relativ einfach dargestellt werden können. Die Verzögerung erhälst du wahrscheinlich weil die Daten nicht schlau aufbereitet sind. Wie speicherst du die Einträge?

Oder du veränderst für jeden Tag der Nullpunkt der Positionierung ...

Könntest Du mir das näher erklären?

Die Lösung mit den Widget ist meiner Meinung nach die bessere. Mit Qt um dem QPainter kannst du den Nullpunkt folgendermassen verschieben: painter.translate(new_x, new_y)
http://doc.qt.nokia.com/4.6/qpainter.html#translate

[mutetella]

@DaMutz:
Nun, so in etwa hatte ich das anfangs auch gelöst: Ein GridSizer (wxSizer entsprechen wohl qtLayout), über das ich pro Tag meine Widgets (damals wxPanel, heute würde ich das mit wxWindow machen) verteilt hatte. Die Einträge pro Tag stellte ich mit wxStaticText dar und ließ diese wiederum mit einem Sizer anordnen.
Ich hatte nicht den Eindruck, dass die Aufbereitung der Daten (zu Testzwecken eh erstmal nur ein dict mit ein paar Einträgen) alles so zäh machte.
Aber inzwischen weiß ich auch a bisl mehr und werde das jetzt nochmal mit einem kleinen Modell testen.
Allerdings gefällt mir die Flexibilität, die man durchs Selbstzeichnen hat, schon sehr. Im Detail hat man mit einem Sizer gefühlt weniger Möglichkeiten zu steuern. Aber da mag auch meine Unerfahrenheit eine große Rolle spielen.
Wie gesagt: Ich werd' mich da nochmal ranmachen.

Gruß
mutetella

[mutetella]

Ich hab' das jetzt nochmals mit einer ganz simplen Kalenderansicht von 42 Tagen mit je 7 Einträgen getestet. Dabei habe ich für jeden Tag ein ScrolledPanel und für jeden Eintrag ein StaticText-widget benutzt. Das alles platzierte ich in einem GridSizer. Auch wenn gerade das ScrolledPanel seine Reize hat und ich mich auch beim StaticText nicht mehr um viel kümmern muss: Selbst zeichnen ist einfach geschmeidiger.
Dass bei 42 Panels auch 42 x ?? Eventprozesse am Laufen sind merkt man einfach. Die widget-view benötigt (auf meinem zugegebenermaßen betagten X20!) ~ 0.10 sec., die vergleichbare dc-view ~ 0.015 sec.
Beim ersten Aufruf einer Ansicht ist der Unterschied sicherlich völlig egal, aber beim Navigieren durch die Monate fühlt sich das dann doch sehr zäh an...

Gruß
mutetella

[Pekh]

Beim ersten Aufruf einer Ansicht ist der Unterschied sicherlich völlig egal, aber beim Navigieren durch die Monate fühlt sich das dann doch sehr zäh an...

Entfernst / Löschst du die Widgets des "alten" Monats eigentlich, wenn du blätterst? Oder haust du dir mit jedem Umblättern den Speicher noch ein Stück weiter voll? Hälst du das ganze Jahr (verdeckt) im Speicher, oder wirklich nur den aktuellen Monat?

[mutetella]

@Pekh:
Ich behalte nur die Koordinaten und aufbereitete Eintragstexte, damit ich das beim Aufruf einer Ansicht, die bereits angezeigt war, nicht nochmals berechnen muss. Die Panels behalte ich natürlich, die müssen ja nicht jedesmal neu erstellt werden. Mit Aufruf der ersten Ansicht sind also in diesem Fall immer 42 Panels vorhanden. Die Text-widgets werden natürlich neu erstellt, dass ich die 'alten' löschen muss, ist mir neu. Mein Speicherbedarf beim Blättern erhöht sich auch nur grob um die Werte meiner abgelegten Koordinaten und Texte, aber das ist erstmal vernachlässigbar...

Gruß
mutetella

P.S. Hab' gerade noch interessehalber nachgemessen, wie sich ein StaticText-widget im Gegensatz zu einem dc.DrawText() verhält. Auch hier zeigt sich, dass allein das Selbstzeichnen von Text ~ 3 mal schneller geht.

[BlackJack]

Ich habe mal aus Neugier ein kleines Beispiel zusammengehackt: http://paste.pocoo.org/show/235525/

Das ist in der Tat sehr zäh. Sollte es IMHO aber eigentlich nicht sein. Keine Ahnung warum das so ist.

[DaMutz]

Hätte ich nicht gedacht, das dies so langsam ist. Aber die generierung der vielen Labels ist das grosse Problem.

Ich habe BJ Variante in etwa in Qt nachprogrammiert und für alle Einträge jeweils ein Label genommen, dann ist es mMn recht schnell. Die Geschwindigkeitserhöhung macht aber mit wx nicht so viel aus. ;-(

http://www.python-forum.de/pastebin.php?mode=view&s=38

[BlackJack]

@DaMutz: Stimmt, die vielen Labels/`wx.StaticText`\s waren die Bremse. Wenn man den Inhalt in ein Widget packt, dann ist es recht flott: http://paste.pocoo.org/show/235806/ (Änderungen zur alten Version: http://paste.pocoo.org/compare/235806/235525/)

[mutetella]

Jetzt könnte man natürlich noch durch das eine oder andere auch das widget-Kalendermodel noch ein wenig beschleunigen, bleibt aber trotzdem die Frage: Weshalb soll ich eine Kalenderansicht per Sizer und Panels erstellen, wenn eine gezeichnete Kalenderansicht immer mit Abstand die schnellere sein wird?
Wahrscheinlich sitzt ihr an den schnelleren Maschinen als ich... Aber wer an einem betagten Laptop oder gar Netbook sitzt wird mit einer aus dutzenden widgets erstellten Ansicht nicht froh...
Was also spricht dafür?

Gruß
mutetella

[lunar]

@DaMutz: Mmmh, ich kann bei Deiner Qt-Variante keine spürbare Verzögerung ausmachen. Bei mir funktioniert das Umschalten flüssig.

@mutetella: Für mich bleibt eher die Frage, warum Du eine eigene Kalenderansicht entwickeln möchtest. Sowohl Qt als auch wxWidgets bieten doch bereits fertige Kalender-Steuerelemente.

[BlackJack]

@lunar: Es soll ein Kalender im Sinne von Mozilla Sunbird sein, also nicht einfach eine Monatsansicht zum auswählen von Tagen, sondern mit Anzeige von Terminen an den Tagen, mit detaillierteren Wochen und Tagesansichten. Ein Terminplaner halt.