Lässt sich der Verweis auf eine Variable abspeichern?
-
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!?
@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
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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit 
)
)-
BlackJack
@mutetella: Nicht die Koordinaten sondern die Daten, die Du da in Listen zusammenfasst.
@BlackJack:
Meinst Du sowas in der Art:
Gruß
mutetella
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)
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)
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?
http://doc.qt.nokia.com/4.6/qpainter.html#translate
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?
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)mutetella hat geschrieben:Könntest Du mir das näher erklären?DaMutz hat geschrieben:Oder du veränderst für jeden Tag der Nullpunkt der Positionierung ...
http://doc.qt.nokia.com/4.6/qpainter.html#translate
@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
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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)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
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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)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 hat geschrieben: 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...
@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.
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.
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)-
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.
Das ist in der Tat sehr zäh. Sollte es IMHO aber eigentlich nicht sein. Keine Ahnung warum das so ist.
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
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/)
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
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
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)-
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.
@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.
@lunar:
Hat BlackJack ja soweit beantwortet. Und selbst das wxDatePickerCtrl lässt sich nur bedingt nutzen, da es nicht so ohne weiteres möglich ist, den Montag als ersten Tag der Woche zu definieren, wie ich bereits über die wxPython Group erfahren hatte:
http://groups.google.com/group/wxpython ... 46e6f1b520
Andererseits lässt sich ein DatePicker mit derselben Klasse, die auch für die Kalenderansicht zuständig ist, relativ leicht darstellen.
Gruß
mutetella
Hat BlackJack ja soweit beantwortet. Und selbst das wxDatePickerCtrl lässt sich nur bedingt nutzen, da es nicht so ohne weiteres möglich ist, den Montag als ersten Tag der Woche zu definieren, wie ich bereits über die wxPython Group erfahren hatte:
http://groups.google.com/group/wxpython ... 46e6f1b520
Andererseits lässt sich ein DatePicker mit derselben Klasse, die auch für die Kalenderansicht zuständig ist, relativ leicht darstellen.
Gruß
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)Ähm... was mir gerade noch einfällt:
Das wxScheduler-Projekt arbeitet daran, ein Calendar-Widget für wxPython zu erstellen. Allerdings ist das noch sehr unausgereift und wie mir scheint inzwischen auch ein wenig eingeschlafen zu sein:
http://code.google.com/p/wxscheduler/
Gruß
mutetella
P.S. Dieser Thread gehört so langsam eher in den wxPython-Bereich...
Das wxScheduler-Projekt arbeitet daran, ein Calendar-Widget für wxPython zu erstellen. Allerdings ist das noch sehr unausgereift und wie mir scheint inzwischen auch ein wenig eingeschlafen zu sein:
http://code.google.com/p/wxscheduler/
Gruß
mutetella
P.S. Dieser Thread gehört so langsam eher in den wxPython-Bereich...
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
)