Simdocks Daseinsberechtigung

Für heute hatte ich einen schönen Vorsatz: Finde einen Ersatz für Simdock, damit du das Projekt aufgeben kannst. Ich bin gescheitert.

Meine Anforderungen an ein Dock sind ziemlich simpel:

• Icons für gestartete Programme und Programmstarter anzeigen
• Diese minimieren können
• Mit Mittelklick neue Instanzen starten
• Einfache Konfiguration (eigentlich nur wichtig: "Im Panel behalten" als Option haben)
• Transparenz unterstützen

Nun ist es natürlich nicht so, dass es kein anderes Programm gäbe, das dem im Grunde gerecht wird. Aber alle scheitern an der Transparenz - bzw am Zusammenspiel mit compton.
Als mögliche Alternative zu Simdock kenne ich diese Programme:

1. Plank
2. Wbar
3. Avant-Window-Navigator
4. Cairo-Dock (Glx-Dock)

Insbesondere Plank ist ein guter Kandidat, Simdock zu ersetzen: Ähnlich schlicht, aktiver entwickelt und mit allen notwendigen und zusätzlich einer Autohide-Funktion. Der einzige Nachteil wäre, dass es keine Pseudotransparenz zu unterstützen scheint. Und ich mag Simdocks Feature, das Programmicon im Dock mit dem Fenstericon zu updaten, was Plank ebenfalls nicht zu können scheint, aber das wäre kein Ausschlusskriterium.

Doch trotzdem funktionieren weder Plank noch die anderen Docks für mich. Wbar ist generell kaputt, die Icons schlieren und es scheint keine Menüs zu haben. Die anderen drei kommen mit compton/xcompmgr nicht zurecht. Hier die Bilder:

Plank

AWN

Cairo-Dock

Sie alle scheitern daran, bei aktiviertem Compositor Transparenz so zu aktivieren, dass der leere Bereich echt transparent ist, bzw bei AWN an der Transparenz des Iconhintergrunds. Dies ist das gleiche Problem, welches ich damals schon hatte und mich überhaupt zum Schrauben am verlassenen Simdock bewegt hat. Damals war es allerdings eine andere Ubuntuversion und andere Hardware, ich habe nicht damit gerechnet, dass das Problem noch existiert.

Hintergrund

Ein Dock muss eigentlich keine echte Transparenz per Compositor unterstützen, da es sowieso nie Fenster hinter sich hat. Die Ausnahme dieser Regel ist die Autohide-Funktion: Wenn das Dock von Vollbild-Fenstern verdrängt wird und vom Bildschirmrand aus über das Vollbild-Fenster fährt, wenn es aktiviert wird. Plank verhält sich so und das ist eigentlich ein schönes Feature.

Ein Dock mit Autohide-Funktion kann also eine Compositor-Funktion gut gebrauchen, ein Dock ohne (wie Simdock) kann probemlos darauf verzichten.

Warum aber ist der schwarze Balken so viel größer als die Docks selbst, was ist der leere Bereich? Ich bin darauf gestoßen, als ich an Simdock gearbeitet habe. Grundsätzlich will ein Dock gerne in Bereiche zeichnen, die erstmal nicht direkt zum Dock gehörig sind. Beispielsweise den Programmnamen in einem Tooltip über den Icons anzeigen oder die Icons nach oben hüpfen lassen, aber ohne den Bereich für sich zu beanspruchen. Ohne in den Code geschaut zu haben gehe ich davon aus, dass Plank und Cairo-Dock sich einen entsprechend großen Bereich als Canvas sichern.
Das wollte ich für Simdock übrigens auch machen, zusätzlich zum bestehenden Fenster mit einer hübschen dafür gedachten Funktion, das hat aber ein wxWidget-Bug verhindert (es hatte schlicht keinen Effekt).

Es scheint nun so, als ob im Zusammenspiel mit AMD-Grafikkartentreibern und xcompmgr/compton die in diesen Docks verwendete Transparenz nicht funktioniert und der von ihnen registrierte Canvasbereich davon ebenfalls betroffen ist.

Simdocks Status

Das soll nicht heißen, dass Simdocks den anderen Docks grundsätzlich überlegen ist - ich bin im Gegenteil überzeugt davon, dass Plank in vielen Fällen eine bessere Wahl ist. Der Vorteil in diesem Fall rührt einfach aus der Beschränkung Simdocks auf Pseudotransparenz - der von Simdock verdeckte Bildschirmhintergrund wird per XServer-Funktion als Bild geholt und hinten eingefügt, was unabhängig vom Compositor zuverlässig zu funktionieren scheint.

Auf Simdocks Seite steht:

• Funktionierende Transparenz
• Menü mit ein paar grundlegenden Einstellungen
• Aktualisierung des Programmicons (wichtig bei Programmen mit Startern, wie Eclipse)
• "Im Starter behalten"-Funktion, zyklisches Minimieren und Öffnen der einzelnen Programmfenster, Instanzenstart per mittlerem Klick

Das sind rein zufällig die grundlegenden Features, die ich gerne in einem Dock hätte.

Gegen Simdock spricht natürlich auch einiges. Zum einen wird es nicht aktiv weiterentwickelt. Ich habe anfangs eingebaut, was ich haben wollte, und danach noch einzelne Bugs gefixt, aber bisher war es das. Zum anderen wird es wenn, dann von mir entwickelt. Das ist von Nachteil, weil ich normalerweise nicht an C++-Programmen arbeite - so gibt es immer noch einen Bug, der manchmal zu Abstürzen führt, der kein mir ersichtliches Schema hat und daher nicht von mir nachstellbar und fixbar ist. Und ich bin durch die nötige Speicherverwaltung schlicht daran gescheitert, Einstellungen on-the-fly übernehmen zu lassen (jemand Lust, mir einen entsprechenden Pull-Request zukommen zu lassen?). Außerdem ist die ganze Library- und Build-Umgebung unter C++ ein für mich schwer durchschaubares Wirrwarr und müsste sicher aufgeräumt werden.

Trotzdem: Für die eigene Desktopumgebung scheint Simdock derzeit meine einzige Wahl zu sein, will ich einen Compositor mit meiner AMD-Grafikkarte nutzen. Oder kennt jemand noch eine von mir übersehene Alternative?