Wie llando im offiziellen Liferea Blog schreibt, sind die getesteten Methoden der vergangenen Wochen zwar teilweise recht erfolgreich, bringen jedoch einen Haufen Probleme und ungelöster Fragen mit. Daher gibt es nun statt einer vollständig neuen Variante die Qual der Wahl zwischen altem Trayicon ohne Unread Count oder neuem Trayicon ohne Transparenz.
Ich möchte dazu noch anmerken, dass auch die alte Implementierung nicht ohne Probleme und Ecksteine ist, da das Icon für Nutzer "verschwindet", die den im Blogpost so gern zitierten Panelslide haben. Das Icon taucht dann irgendwann wieder auf, wenn es neu gezeichnet wird. Bis dahin ist jedoch finito (aufgrund des fehlenden Expose). Wer mag, kann es gerne testen (erfordert einen Liferea Neustart, da die DrawingArea des Trayicons mit Unread Count ansonsten den Trayiconhintergrund weiterhin in schöne Monotonität hüllt – ein Problem, was viel viel mit dem Scheitern einer Neuimplementierung zu tun hat).
Ich biete deshalb auch einen Prototypen als Patch an, an dem wir lang rumdiskutiert und getestet haben.
Der Code ist ursprünglich noch für den 1.2 Branch von Liferea, sollte jedoch auch halbwegs sauber auf 1.3 und 1.4 anwendbar sein. Qualität ist eher mager (da halt eigentlich zum testen), aber besser als garnix. Ich werde natürlich weiter an der Sache herumbauen, Indianerehrenwort 
.
So, damit jetzt kein Mißverständnis aufkommt und jeder weiß, warum dies nicht die Lösung schlechthin, aber ein recht akzeptabler Kompromiss ist: Der Code setzt voraus, dass beim Start von Liferea das Panel sichtbar ist, damit der Hintergrund des Panels über X Clientfunktionen (in diesem Fall durch GDK) bezogen und gespeichert werden kann. Wir haben mit einer Version rumexperimentiert, die auch dynamisch bei jedem Trayiconupdate den Hintergrund bezieht, war großer Schmuh (im Blogpost wird klar warum, das Problem ist auch auf GTKs seltsame Art des Offscreen Handling zurückzuführen und das dolle Problem mit dem Windowbereich der DrawingArea, die man nicht so einfach ausblenden kann).
Diese Version hier bezieht den Background also nur am Start, speichert ihn und malt ihn danach immer wieder. Für 90% der Normalsterblichen (und auch für die Panelslider) sollte dies ein ganz guter Kompromiss sein, will man sich nun partout nicht von dem Unread Counter trennen.
Außerdem bringt dieser Patch, wie gewünscht, größere Icons (Xara Sourcen inklusive).
Den Patch kann man sich hier herunterladen (traytest3.patch und jeweils ein Bilderset!). Die Bilder gehen in das Pixmaps Verzeichnis, der Patch wird mit patch -p0 < traytest3.patch angewendet.
Jetzt noch für interessierte Programmierer, die aus dem Kauderwelsch in den Klammern nicht schlau wurden: Die Idee bei jedem Expose auf Veränderung des Hintergrundes zu testen ist aus Performancegründen nicht praktikabel. Es erfolgt nicht nur ein Expose, sondern im Schnitt 5-6 Stück auf einmal. Da wir hier über X Clientfunktionen reden, laufen diese asynchron zu GTKs logischem Programmablauf. Das ist das erste Problem. Das zweite Problem ist, dass GTK eine mucho seltsame Art hat, das Unterelement Window der DrawingArea (den Bereich, auf den wir hier das Trayicon mit Unread Count zeichnen) zu handlen. Für ein erfolgreiches Regrabben des Hintergrunds muss der Bereich natürlich leer sein. Dank dem Window Element, welches sich allerdings weder durch unrealize(), noch durch hide() oder destroy() wirklich sinnvoll handlen lässt, bleiben sowohl der alte Hintergrund als auch das alte Icon im neuen Hintergrund erhalten – was bei den neuen semitransparenten Icons mächtig schlecht ist. Diese Probleme bieten sich nicht, wenn man den Hintergrund automatisch einmal am Programmstart während der Trayiconinstallation grabbt und speichert (da das Icon eh leer ist).
So, und nun viel Spaß .
. Da der Prozess auch nicht lange dauert, ist das evtl. mal eine kurzweilige Beschäftigung für einen verregneten Sonntagnachmittag. Ich sehe schon die ersten Systeme mit minimalem X, ZSNES und 600 MB Roms durch den Channel geistern 
. 
Recent Comments