Ein kurzer Blogrückblick auf 2023
Letztes Jahr schrieb ich trotz Umzug relativ regelmäßig in diesen Blog. 2023 ähnelte sich da sehr: Wieder änderte sich einiges im Hintergrund, wieder war der Blog mir eine willkommene Konstante.
Dieses Jahr habe ich 106 Artikel geschrieben. Da sind die Linksammlungen mitgezählt, die fast jeden Freitag erschienen.
Die drei längsten Artikel waren:
- Deep Space 9 war das beste Star Trek und die falsche Richtung (24387 Zeichen)
- 15 Jahre Serendipity als Entwickler - ein Rückblick und ein Ausblick (23187 Zeichen)
- Zum jetzt spielbaren Cyberpunk 2077 (19981 Zeichen)
Die Verteilung gefällt mir – einmal Serie, einmal FOSS-Entwicklung und einmal ein Computerspiel, das trifft den gewollten Themenmix im Blog ganz gut. Und den angekündigten DS9-Artikel wirklich bringen zu können hatte mich gefreut.
Themenwahl dieses Jahr war ansonsten ähnlich wie zuvor, die Blogkategorien wurden allgemein so abgedeckt:
- Spiele: 18 Artikel
- Medien: 14 Artikel
- Linux: 10 Artikel
- Technikzeugs: 8 Artikel
- about: 7 Artikel
- Zeitgeschehen: 1 Artikel
- Textformen: 1 Artikel
- Code: 1 Artikel
Das sind mehr Medienartikel, aber weniger Spieleartikel als 2022. Das war mir ja wichtig, nicht nur Spiele hier in den Blog zu packen. Mit der Entwicklung bin ich daher zufrieden.
Insgesamt durfte ich im Blog 130 Kommentare verzeichnen. Davon waren 50 von mir. Mit Trackback und Pingbacks bekam die Kommentartabelle 231 neue Zeilen.
Die meistkommentierten Artikel waren:
Die Kommentare waren also recht verteilt, was mich gerade etwas überrascht. Ich habe die Kommentaraktivität als positiv wahrgenommen und daher mit einem längeren Kommentarthread gerechnet, aber scheinbar sind mehr Artikel mit zumindest wenigen Kommentaren angenehm.
Bei Google sah die Platzierung in der Suchmaschine so aus:
Das sind etwas mehr Klicks als letztes Jahr, aber weniger Impressionen. Das erscheint mir erstmal wie etwas positives, da mehr Artikel zur Suche gepasst haben dürften. Insbesondere Samsung A3 (2016) auf Android 11/LineageOS 18.1 updaten, der ist zum meistangeklickten Artikel aufgestiegen.
Beim Blog selbst hat sich nicht viel geändert. Das ist immer noch Serendipity 2.4.0 mit vultr als Hoster. Es gibt zwar mit 2.5-beta1 eine neue Version, aber da auf dem Server noch eine ältere PHP-Version läuft war das Upgrade nicht zwingend. Das dürfte sich nächstes Jahr ändern. Wo sich etwas getan hat ist beim Design, da kam ein Dark-Mode dazu und auch im hellen Modus wurden die Farben für einen besseren Kontrast etwas angepasst. Gerade bei den Linkfarben fand ich den Effekt davon sehr angenehm.
Soviel zu 2023. In Sachen Blog war es ein ruhiges Jahr ohne Umwälzungen, mit in etwa so viel Artikeln und Kommentaren wie zuvor, wovon nur der Samsung-Artikel in Sachen Reichweite etwas herausstach. Wenn ich auf das Jahr zurückblicke sehe ich aber schon eine Besonderheit: Es war schon einiges an Rückbesinnung, mit der Erinnerung an die Lan-Parties, der Besprechung der Serendipity-Entwicklungszeit und der Nostalgie im DS9-Artikel. Da setzte wohl der Bloggeburtstagsartikel am Jahresbeginn etwas den Ton.
Für das nächste Jahr habe ich für den Blog keine besonderen Pläne. Aber es dürften sich bei mir anderweitig ein paar Dinge ändern, was sich dann sicher auch auf den Blog auswirken wird. Ich rechne im Jahresverlauf mit deutlich weniger und mit kürzeren Artikeln.
An dieser Stelle ein Danke an alle Leser und an alle Kommentatoren. Euch allen wünsche ich ein gutes neues Jahr.
Ich berichtete von der Bilbao International Games Conference
Am Freitag und Samstag letzter Woche fand ich mich auf der Bilbao International Games Conference in einer Reporterrolle wieder.
BIG via GG
Und das kam so:
Die BIG ist eine spanische Spielekonferenz, hauptsächlich für Entwickler bzw die Spieleindustrie. In einem Konferenztrack halten dort Entwickler Vorträge oder werden welche gehalten, die Spielemacher interessieren könnten. Gleichzeitig ist es ein Ort für Treffen untereinander, für die Publishersuche und für Interviews mit der Presse. Außerdem gibt es eine Ausstellungshalle, in der vor allem Indie-Entwickler ihre Spiele vorstellen und die dann meist auf Publishersuche sind. Und auch Spielereleases gab es.
Seit einigen Jahren habe ich einen Account bei der deutschen Spieleseite Gamersglobal. Ein halbes Mitmachmagazin, habe auch ich dort (für die größere Reichweite) Artikel veröffentlicht. Stammleser dürften sich erinnern, meistens verlinke ich die dann hier, manchmal waren es auch alternative Versionen von Blogartikeln. GamersGlobal nun war angefragt worden, ob sie nicht über die BIG berichten würden. Die Redaktion konnte das aber im vorweihnachtlichen Trubel nicht. Also wurde bei den anderen Community-Schreibern gefragt, bei denen die Zeit aber auch zu knapp war. Ich aber konnte und wollte.
Für mich war es perfektes Timing. Als die Anfrage reinkam war ich gerade aus Mexiko zurück, wo mein Spanisch sich stark verbessert hatte. Kurz vor Weihnachten war mein Terminkalender recht leer (außer dem generellen Zeitmangel für meine Softwareprojekte…). Und Messeberichte hatte ich ja schon gemacht, auch über Spiele schreibe ich seit Jahren, aber die Kombination hatte ich noch nie und diese offizielle Presserolle auf einer Konferenz schon gar nicht. Das reizte mich.
Die Ergebnisse
Meine Sorge war natürlich, dass es nicht klappen könnte. Dass entweder die Vorträge und die gezeigten Spiele langweilig sein würden, ich Interviewmöglichkeiten verstotterte oder den Spagat nicht schaffe würde zwischen dem Teilnehmen an der Konferenz und dem Schreiben darüber. Es war unbegründet. Sowohl zu den Vorträgen als auch zu den gezeigten Spielen ließen sich problemlos noch auf der Konferenz News schreiben. Dabei half auch ein ordentlicher Presseraum. Selbst mein altes LG G5 bewährte sich als Messe-Fotoapparat, zumindest waren die Bilder nicht inakzeptabel schlecht (wobei, sollte ich das öfter machen wäre es Rechtfertigung für ein neues Telefon mit besserer Kamera, oder für eine separate Kamera).
Die Liste bisher:
- Ein Besuch auf der Bilbao International Games Conference 2023 (Fotogalerie)
- Tiny Garden angespielt // Erntet Lob
- Atmosphärisches Puzzle-Adventure Evolution angespielt
- Wie Larian Baldur's Gate 3 entwickelte
- Das Metroidvania Eden's Guardian angespielt
- Titanium Awards verliehen, Zelda TotK ist Spiel des Jahres
- Les Mills XR Dance für die Quest 2 und 3 gezeigt
- Warum manche Spiele ständig reduziert sind
- Tekken-Leiter Katsuhiro Harada zur Zukunft von Prügelspielen
- Blasphemous 2 war ein schwieriger zweiter Teil
Schaut da gerne mal rein. Die Liste soll auch zeigen, dass es überhaupt kein Problem war, spannende Themen zu finden. Und mit mehr Leuten vor Ort hätte man locker die doppelte Zahl an News und Berichten schreiben können.
Ein bisschen Glück war bei der Sache auch dabei, natürlich. Zum einen, dass der Vortrag zu den Spielepreisen sehr früh war, und mir da sofort einfiel, wie man das für die Leser verpacken könnte (der Inhalt war ja ursprünglich an Entwickler und nicht an Käufer gerichtet, das musste umgedreht werden). Danach fiel das bei den Folgevorträgen recht einfach, der Ball war im Rollen. Zudem lief mir mit Iván Lerner ganz früh ein absolut sympathischer und messerscharf denkender Reporter über den Weg, der mir ein paar wirklich hilfreiche Ratschläge geben konnte und der eine fantastische Begleitung für die Feiern am Abend war. Ein absoluter Glücksfall.
In kurz, die BIG-Konferenz in Bilbao war spaßig und mir machte die Rolle als Konferenzreporter ebenfalls Spaß. Es gab auf ihr nicht die großen Enthüllungen oder die Möglichkeit, als erster überhaupt ein großes neues Spiel anzuspielen, zumindest bekam ich sowas nicht mit. Aber sie lieferte einen interessanten Einblick in die Spieleindustrie, besonders in die spanische Szene – und die ist spannend, denn sie macht international relevante Spiele.
Ersteindruck: Roborock E5 vs Roomba 615
Die letzten Jahre hat der Roomba 615 meine Wohnung gesaugt, in Zukunft sollte das der Roborock E5 übernehmen. Warum wechseln, was sind die Unterschiede und wie schlägt sich der neue?
Wechselgrund Routenplanung
Hauptgrund für den Wechsel ist die versprochene bessere Routenplanung. Der Roomba 615 folgt beim Reinigen scheinbar einfachen Regeln. Die sorgen dafür, dass er mit genug Zeit durch die ganze Wohnung fährt – aber dafür viel länger braucht, als wenn er effizient nur ungesaugte Bereiche anfahren würde. Verbunden mit dem doch nervigen Lärmpegel und seiner Eigenheit, immer wieder aus meinem Büro nicht mehr rauszufinden, wurde der alte Roomba nervig. Das machte seinen Zweck kaputt eine Alltagserleichterung zu sein, außerdem wurde er deswegen immer seltener genutzt.
Beim Roborock E5 soll die Navigation besser funktionieren. Dieser baue eine interne Karte und fahre dann gezielt durch die Wohnung. Gleichzeitig leiser verspricht das, die Wohnung in kürzerer Zeit mit wesentlich geringerem Nervfaktor sauber gemacht zu bekommen.
Was sonst für den E5 sprach: Internetlosigkeit und der Preis
Aber dieses geplante Vorgehen beherrschen fast alle modernen Saugroboter, außer den allergünstigsten. Warum kaufte ich den Roborock E5?
Zum einen, weil er mit einer Fernbedienung kommt und die App-Anbindung tatsächlich optional zu sein scheint. Roborock, eine chinesische Firma mit Verbindungen zu Xiaomi und damit unter permanenten Spionageverdacht, verspricht die Optionalität der App-Anbindung für alle Saugroboter. Sie erklärt aber nicht, welche Funktionen dann noch funktionieren. Fällt z.B. bei einem eher darauf ausgelegtem Modell wie dem S8 die Internetanbindung weg, funktioniert dann die intelligente Routenplanung noch? Beim E5 funktioniert sie scheinbar immer, zudem gibt die Fernbedienung Zugriff auf ein paar nützliche Funktionen wie die Einstellung der Saugintensität (und damit dem Lärmlevel), ohne das Gerät ins heimische Wlan lassen zu müssen.
Saugroboter anderer Hersteller starten Internetberichten teils gar nicht, wenn sie nicht ins Wlan kommen, oder sind definitiv bei der Adaption ihrer Navigation dann beschnitten. Deutlich kommuniziert wird die Situation um die nötige Internetanbindung leider bei fast keinem Hersteller, das Statement von Roborock war die große Ausnahme. Daher war es eine aufwändige Recherche, den E5 als mögliche Option herauszufinden, und Roborocks Versprechen gab den Ausschlag, die Auswahl schließlich auf Geräte dieses Herstellers zu beschränken. Mit der Fernbedienung als Manifestation davon war der E5 doppelt attraktiv.
Zweiter positiver Aspekt des E5 ist sein Preis. Er beherrscht moderne appgestützte Funktionen wie die Raumerkennung nicht, nur die Karte der gesamten Wohnfläche lässt sich in der App wohl anzeigen. Dementsprechend kann man ihn nicht anweisen, jetzt die Küche zu putzen – er kann nur ganz oder gar nicht. Völlig ausgereift sei die intelligentere Navigation zudem auch nicht. Letzteres kann ich bestätigen, gerade fährt er zum zweiten mal durch die Küche (aber gut, die Karte muss sich ja erst aufbauen). Und seine Wischfunktion ist einfach ein Tuch, das mit Wasser benetzt wird, keine Borsten oder Vibrationen unterstützten sie und Teppiche vermeidet er auch dann nicht. Er ist also in vielerlei Hinsicht ein Budgetmodell und entsprechend auch deutlich günstiger als viele Alternativen.
Unterschiede zum Roomba 615
Der Hauptunterschied zum Roomba 615 ist also die Routenplanung. Der Roborock E5 fährt in langen Linien durch die Wohnung und scheint wirklich gezielt Bereiche anzufahren, die noch nicht gesaugt wurden. Das ist ein Riesenvorteil und wirkte im ersten Test sehr angenehm! Aber die weitere Zeit muss zeigen, ob er wirklich die gesamte Wohnung durchfährt und dann auch wirklich das Saugen abbricht wenn er überall war, nicht erst, wenn der leere Akku das vorgibt. Schließlich hat auch der Roomba irgendwann das Saugen beendet, und in den ersten Tests schien der E5 länger weiterzumachen als sinnvoll erschien.
Beim Lärm schneidet der E5 besser ab – zumindest auf dem Laminatboden hier. Da ist er etwas leiser und der Lärmcharakter gleichförmiger, der 615 rödelt schlicht mehr. Fährt der E5 aber über Teppich, schaltet er in einen Turbomodus um, dann wird er sogar lauter als der alte Roomba je war. Die Saugintensität und damit der Lärm lässt sich beim Roborock einstellen, per Fernbedienung oder App. Der leisere Modus ist dann zwar wirklich nochmal ein bisschen leiser, aber der Unterschied zum Standardmodus ist nicht riesig.
Beide Saugroboter vermeiden herumstehende Objekte nicht völlig. Beim E5 hat mich das ein bisschen gewundert, hat er doch eine Kamera eingebaut, zumindest verstehe ich so die Herstellerbezeichnung OpticEye (auch wenn die nicht für die Primärnavigation benutzt wird, die basiert auf Gyroskopen). Trotzdem dozt er fast genauso gegen Tischbeine wie der völlig kameralose 615, nur leicht vorher abbremsend. OpticEye ist also wohl in der Praxis nur ein Näherungssensor, wie der Roomba ihn auch hat. Zusätzlich wird die Heftigkeit der Kollision durch einen vorne angebrachten Stoßdämpfer gemindert.
Bei anderen Hindernissen gibt es Unterschiede. So blieb der 615 immer auf den Streben des Wäscheständers hängen, halb in der Luft hängend kam er nicht weiter und schaltete sich schließlich ab. Der E5 hängt bei den gleichen Streben ebenfalls kurz in der Luft, gibt sich dann aber einen Ruck und bleibt nicht stecken. Super! Dafür hat er mehr Probleme mit Kabeln als der Roomba, so verfing er sich direkt in den Stromkabeln der Katzenfutterautomaten, mit denen der Vorgänger noch nie ein Problem hatte. Die werde ich nun anders verlegen müssen.
Zur Saugleistung kann ich noch nicht viel sagen. Die Herausforderung bei uns sind lange Menschenhaare und sehr viele Katzenhaare. Mit den Menschenhaaren hatte der Roomba ernste Probleme, sie verfingen sich in seiner Bürste und zerschnitten sie richtig. Aber zumindest solange die Bürstenborsten nicht ganz abgeschnitten waren schaffte er es doch, die Wohnung deutlich sauberer zu machen. Meinem Ersteindruck nach schafft der E5 das genauso, saugt aber ebenfalls nicht so perfekt als würde man es selbst machen, braucht dafür jedoch weniger Zeit als der Roomba.
Der Staubbehälter des E5 ist ein bisschen kleiner (640ml statt 700ml). Ob der waschbare Filter gut funktioniert kann ich nicht ordentlich messen, die Idee aber finde ich gut.
An den E5 kann man auch einen Wischmop anbringen, ein Wasserbehälter würde den dann befeuchten. Da hier in der Wohnung Laminat ist habe ich den gleich in der Packung gelassen. Ich will aber noch testen, ob zumindest das gelegentliche Wischen damit auf dem Laminatboden möglich ist. Der Roomba 615 hatte keine Wischfunktion.
Beiden gemein ist, dass Wlan nicht benötigt wird. Aber der E5 hat eine optionale Appunterstützung, die ich nicht getestet habe. Der 615 hat gar kein Wlan.
Anfangsprobleme mit diesem E5
Nicht unerwähnt bleiben soll, dass ich zu diesem Zeitpunkt noch nicht sicher bin, ob der gekaufte E5 (ein C-Modell, angeblich ein reparierter Rückläufer) nicht doch noch zurückgeht. Beim ersten Test hatte er für eine kurze Weile wunderbar gesaugt, danach aber klappte das Docken nicht – er fuhr zum Ladedock und auch drauf, blieb aber dann nicht drin stehen. Beim manuellen Hereinsetzen gab es keine Rückmeldung, dass das Laden nun klappt. Erst eine Stunde später kam plötzlich eine Fanfare vom Roboter. Ich ging davon aus, dass der Akku kaputt sei.
Danach aber funktionierte der Roboter, auch das Docken funktionierte jetzt mehrmals im ersten Anlauf und die Akkukapazität wirkte völlig okay. Hier muss ich also noch beobachten, ob das ein einmaliger Ausrutscher war oder ob dieser E5 nicht doch einen Schlag weg hat.
Der Roborock E5 bietet dem ersten Eindruck nach genau den Sprung, den ich mir erhofft habe. Ohne unbedingt jedes mal perfekt zu saugen, macht er die Wohnung genauso dadurch sauberer, dass er viel öfter saugt als ich es selbst machen würde. Aber anders als der Roomba 615 macht er das nicht mehr per Zufallsnavigation, sondern seine Liniennavigation ist nachvollziehbarer. Dadurch ist er weniger nervig, wobei dabei auch der etwas geringere Lärmpegel hilft.
Gleichzeitig vermeidet er den Sprung in unsere dystopische Jetztzeit, in der mit Kamera ausgestattete Roboter, dazu mit proprietärer Software ausgestattet und oft mit Verbindungen zu Diktaturen wie China belastet, ohne jegliche Kontrolle nach Hause funkend durch privateste Wohnungen fahren. Will man keine solche Unsicherheit wird sonst oft der Anker/Eufy RoboVac 11S empfohlen, der ist aber bei der Routenplanung genauso beschränkt wie mein alter Roomba 615, wäre also keine Verbesserung. Und mit Valetudo einen internetbewehrten Roboter zu entschärfen, wie bei GNU/Linux.ch gut beschrieben wurde und was als zweite Alternative gilt, war selbst mir zu aufwändig.
Ein paar Dinge könnten besser sein:
- Weniger laut geht immer.
- Kleiner und flacher wäre ebenfalls nett, natürlich nicht auf Kosten der Kapazität des Saugbehälters und des Akkus.
- Der Roboter sollte Objekte vermeiden können, insbesondere sich nicht in Kabeln verheddern. Diese Objekterkennung und Vermeidung fehlt dem E5 leider komplett.
- Die Navigation sollte perfekt funktionieren, der Roboter sich so effizient bewegen wie möglich.
- Der perfekte Saugroboter hätte eine gute Wischfunktion, so minimal nass um selbst auf Laminat zu funktionieren, die (wie der Roborock S7 und S8 es wohl können) für Teppiche dann deaktiviert wird.
Aber bei der derzeitigen Produktentwicklung in diesem Bereich ist nicht damit zu rechnen, dass je ein Roboter mit diesen Verbesserungen auf den Markt kommt und ohne App- und Internetanbindung auskommt. Von daher bin ich mit dem E5 erstmal zufrieden.
Simdock jetzt mit Compositing und GTK3
Simdock ist mein Dock für den Linuxdesktop, das ich seit ein paar Jahren pflege. Jetzt konnte ich dem Code ein großes Update verpassen und damit das Projekt für die nächste Zeit absichern.
Kurzfassung
- Simdock läuft nun mit der GTK3-Version von wxWidgets, bei mir ist das das sehr neue wxWidgets-3.2.4. Dadurch wird es auch auf modernen Systemen wieder kompilieren.
- Durch den Wechsel zu GTK3 musste auch die genutzte Library Wnck aktualisiert werden, die Version 1 zuvor setzte auf GTK2, das kollidierte. Nebeneffekt davon ist, dass für die dynamischen Programmanzeigen größere Icons gewählt werden sollten.
- Dank der neuen Version von wxWidgets konnte durch wenige Codeänderungen Compositing für den Dockhintergrund aktiviert werden. Die Pseudotransparenz funktioniert weiterhin, wenn kein Compositor am Laufen ist.
- Es werden wieder AppImages gebaut. Die gab es für Simdock schonmal, die waren aber durch den Wegfall von Travis CI ausgefallen. Die AppImages hatten (zumindest aber auf meinem System) noch einen Bug mit dem neuen Compositing, mehr dazu unten.
Der allgemeine Hintergrund des Updates
Simdock lief die letzten Jahre relativ zuverlässig vor sich hin. Aber der Wechsel zu GTK3 war eine große Gefahr für die weitere Existenz des Projekts und die Migration jahrelang durch eine fehlende Funktion von GTK3 blockiert.
Nun war der Wechsel aber unumgänglich, es musste etwas passieren. Denn selbst auf meinem eigenen System konnte ich Simdock nicht mehr bauen. Void Linux hatte wxWidgets auf GTK3 umgestellt, ohne die GTK2-Version weiterhin bereitzustellen. Und das alte AppImage lief auch nicht, neue wurden sowieso nicht mehr gebaut. Ich rechnete eigentlich damit, das Projekt aufgeben zu müssen – und stolperte dann gestern doch über die Lösung.
Als Simdock vor ~2 Monaten für mich wegbrach hatte ich noch mit keiner Lösung gerechnet und mir stattdessen Alternativen angeschaut. Und tatsächlich auch gefunden: Plank ist mittlerweile eine hervorrage Alternative. Es fehlen die konfigurierbaren Starter, dafür kann es sich selbst verstecken (Auto-Hide) und und ist so platzsparend, außerdem hatte es schon lange echte Transparenz. Ich nutzte es mit Openbox und jetzt nochmal mit IceWM (da kollidierte es erst mit meiner Konfiguration, aber mit der Versteckenfunktion passte es). Die Existenz der Alternative war entspannend! Aber jetzt nachziehen zu können befriedigt dann doch meinen Ehrgeiz. Und es war die bessere Lösung in meiner derzeitigen Projektaufräumaktion, so statt dem Aufgeben genau wie bei izulu nach Jahren des Zeitmangels die Modernisierung umsetzen zu können.
Technische Erklärungen
Warum war der Wechsel zu GTK3 so problematisch? Es sollte überraschen, denn wxWidgets abstrahiert das Toolkit eigentlich weg, ob da jetzt GTK2, GTK3 oder gar QT läuft sollte egal sein. Gleichzeitig ist wxWidgets eines dieser großartigen Projekte, bei denen Upgrades generell schmerzlos sind, ich musste genau null Zeilen wxWidget-Code anpassen.
Das Problem war diese Funktion: gdk_pixmap_foreign_new(). Simdock benutzte sie, um den Hintergrund des X11-Desktops zu holen und den dann als Hintergrund des eigenen Fensters zu setzen. Klassische Pseudotransparenz. Und für diese Funktion gibt es in GTK3 einfach keinen direkten Ersatz. Der Code sah leicht vereinfacht so aus:
wxBitmap* backImage = new wxBitmap();
WnckScreen *screen = wnck_screen_get_default ();
// The XID of the background pixmap
Pixmap pm = wnck_screen_get_background_pixmap(screen);
if (pm != None) {
wxBitmap* backImage = new wxBitmap(
gdk_pixmap_foreign_new(
pm
)
);
return backImage;
}
Da wurde also auch Wnck genutzt, dessen Details sich ebenfalls ändern würden, das verstellte weiter den Blick auf die Lösung. Es gibt einfach keinen dokumentierten Weg, die Pixmap des XServers mit GTK3 in ein Grafikobjekt zu quetschen um sie dann wxBitmap zu übergeben.
Stattdessen sah meine Lösung schließlich so aus:
wxSize sz = wxGetDisplaySize(); wxBitmap* backImage = new wxBitmap( gdk_pixbuf_get_from_window( gdk_x11_window_foreign_new_for_display( gdk_display_get_default(), gdk_x11_get_default_root_xwindow() ), 0, 0, sz.GetWidth(), sz.GetHeight() ) );
Das benutzt jetzt also GDK-Funktionen ohne den Wnck-Umweg. Und war nur möglich, weil ich mit der Hilfeseite zu X Window System Interaction endlich über die passende Dokumentation gestolpert war. Der Code holt sich das Root-XWindows mit gdk_x11_get_default_root_xwindow(), macht daraus ein GDK-Window mit gdk_x11_window_foreign_new_for_display und davon kann gdk_pixbuf_get_from_window dann eine Grafik ziehen. Dass dadrin ebenfalls gdk_display_get_default benutzt wird folgte direkt der Dokumentation.
Jedoch: Das ist nicht ganz das gleiche! Denn die Grafik beinhaltet auch alle offenen Fenster. Es ist eben nicht der X-Hintergrund, an den ist einfach nicht ranzukommen. Doch für Simdock war das gut genug: Normalerweise sind eh keine Fenster hinter einem Dock, und ich schaffte es, Simdock vor dem Ziehen dieses Screenshots auszublenden. Flickert ganz kurz, aber da das nur bei Hintergrundbildwechseln passiert sollte das okay sein.
Damit war die Makefile anpassbar. Wnck-3.0 und wxWidgets-GTK3 konnten ins Projekt, Simdock damit wieder auf modernen Systemen gebaut worden. Und die nächste langjährige Baustelle war angehbar.
Echte Transparenz mittels eines Compositors hätte das Problem mit der oberen schwierigen Umsetzung von Pseudotransparenz umgangen. Diese Transparenz sollte wxWidgets eigentlich können, es gibt mit wxBG_STYLE_TRANSPARENT einen passenden setzbaren Hintergrund, der echte Transparenz bringen soll. Doch bei mir hatte das in vorherigen Tests nie geklappt.
Mit GTK3 und einer neuen Version von wxWidgets testete ich das erneut. Und tatsächlich: Es brauchte nur minimale Codeänderungen und die Transparenz lief direkt. Ein echter Durchbruch. Simdock soll weiterhin Pseudotransparenz unterstützen – das war das originale Alleinstellungsmerkmal des Programms, weswegen ich es überhaupt übernommen habe – aber echte Transparenz zusätzlich anbieten zu können ist super. Vor allem, wenn es jegliches Flickern vermeidet.
Die Lösung folgt genau der Dokumentation, wie ich sie vorher schonmal verlinkt hatte: Im Konstruktor des wxWindow, in diesem Fall dem wxFrame, SetBackgroundStyle(wxBG_STYLE_TRANSPARENT); setzen und erst danach mit Create(parent, ...); das Fenster erstellen. Vorher sah der Anfang des Konstruktors so aus:
MyFrame::MyFrame (wxWindow * parent, simSettings set, ImagesArray * array,
wxWindowID id, const wxString & title, const wxPoint & pos,
const wxSize & size, long style):
wxFrame (parent, id, title, pos, size, style)
{
…
SetBackgroundStyle(wxBG_STYLE_PAINT);
}
Daraus wurde das hier:
MyFrame::MyFrame (wxWindow * parent, simSettings set, ImagesArray * array,
wxWindowID id, const wxString & title, const wxPoint & pos,
const wxSize & size, long style):
wxFrame()
{
// This enables full composited transparency:
SetBackgroundStyle(wxBG_STYLE_TRANSPARENT);
Create(parent, id, title, pos, size, style);
…
}
Da veränderte sich also ebenfalls die Definition des Konstruktors, plus dem schnelleren Setzen von wxBG_STYLE_TRANSPARENT vor dem Create.
Ausstehende Probleme
Simdock hat relativ früh AppImages bereitgestellt. Ich war auf der Froscon in einem Vortrag des AppImage-Projekts und fand die Idee super. Die wurden aber die letzten Jahre nicht mehr gebaut, weil die Travis-CI nicht mehr kostenlos war.
Also stellte ich die Buildpipeline wieder her. Diesmal mit Github-CI, und weil linuxdeployqt einen Fehler produzierte wechselte ich zu linuxdeploy mit dem GTK-Plugin. Das funktionierte an sich! Aber: Das AppImage bleibt bei mir schwarz, wenn Compositing aktiviert ist.
Ich habe ein Issue dafür auf, in dem ich auch mehr der Details zu den AppImages erkläre. Den gewählten Ansatz finde ich wirklich geschickt, die Logik hauptsächlich in eine zweite Makefile zu packen. Das hält die Github-CI-Workflowdatei simpel. Aber das Ergebnis muss eben auch funktioniere. Bis sich da eine Lösung auftut werde ich das AppImage weiter bauen lassen, aber nicht bewerben.
Mit all den Änderungen hat Simdock technisch einen großen Schritt getan und ich freue mich, dass das möglich war. Es wäre zu schade gewesen, das Projekt wegen den GTK-Migrationsproblemen aufgeben zu müssen. Und wer ein nettes Dock mit gutem Fenstermanagement sucht, mit Plank aber aus irgendwelchen Gründen nicht warm wird, dem kann ich Simdock jetzt wieder guten Gewissens empfehlen. Die Installation per Kompilierung wird im Readme beschrieben.
