highcal, nhkd, xlocatemouse und Elefanten

2020-05-21

highcal (und „be“)

gitodo war ein TODO-Tool, das ich Ende 2010 geschrieben habe. Das Teil hat recht viele Änderungen durchlaufen. Am Anfang war es ein Shellskript, das auch mit msysgit funktioniert hat, weil ich das damals benutzen musste. Später wurde es dann als Experiment in Ruby neu geschrieben, weil ich mehr über die Sprache lernen wollte.

Sagen wir’s mal so: Ruby und ich sind nicht so kompatibel. Mein Code sah dann eh stark nach Python aus. Belassen wir’s mal dabei, um Ruby geht’s mir jetzt nicht.

gitodo wurde kürzlich durch be abgelöst. Das ist ein wirklich kurzes Shellskript, nicht kompatibel mit gitodo, hat weniger Features – macht aber das, was ich brauche.

Im gitodo-Projekt war auch ein Kalender mit dabei, highcal. Der kann Tage hervorheben:

highcal

Leider war die Performance davon nie besonders gut. Der erste Start dauert 0.2 Sekunden auf meiner Maschine, danach (wenn alles im Cache ist) dann etwas mehr als 0.05 Sekunden. Das bemerkt man. Es ist lästig. Platt gesagt, ist das einfach der normale Ruby-Overhead:

$ time ruby -e 'puts "hi"'
hi

real  0m0.049s
user  0m0.040s
sys   0m0.010s

highcal habe ich jetzt in C neu geschrieben. Weil ich faul bin, kann diese Version nicht mit historischen Datümern umgehen.

nano hot key daemon – nhkd

Damals, als ich dwm benutzt hatte, waren alle meine globalen Hotkeys in dwm konfiguriert. Das hat den großen Nachteil, dass man bei Änderungen dwm neu kompilieren und neu starten muss. Das ist einer der Gründe, warum katriawm kein eingebautes Key-Handling hat und stattdessen auf externe Programme wie sxhkd angewiesen ist.

Kurz nachdem ich mit katriawm fertig war, sind ein paar Features aus sxhkd rausgeflogen, von denen ich abhing. Seitdem hing ich bei Version 0.5.5 fest. Kürzlich hat sxhkd dann aufgehört, mit GCC 10 zu kompilieren. Das wird sicher bald gefixt, aber es würde eben auch heißen, dass ich diese Änderungen auf 0.5.5 backporten müsste. Meh.

Stattdessen habe ich nhkd zusammengestöpselt. Es baut auf Code von dwm auf. Es heißt „nano“, weil’s wirklich klein und in der Funktionalität eingeschränkt ist.

Es gibt nämlich ein ganz bestimmtes Problem mit sxhkd 0.5.5: Man kann zwar Bindings für Maus-Events konfigurieren, aber bei denen geht die Reihenfolge kaputt. Klicken, ziehen, loslassen – jedes Motion-Event beim Ziehen ist ein eigener Prozess und die alle laufen quasi in beliebiger Reihenfolge. Heutige Computer haben kein Problem mit den ganzen Prozessen, aber die Reihenfolge ist halt wichtig. Deswegen wurde das auch aus sxhkd entfernt.

nhkd umgeht das Problem, indem eine Seriennummer an die gestarteten Programme angehangen wird. Sieht so aus ($x $y $window $serial):

nhkd: spawn [katriac client_move_mouse down 2154 719 46137347]
nhkd: spawn [katriac client_move_mouse motion 2154 719 46137347 1]
nhkd: spawn [katriac client_move_mouse motion 2154 719 46137347 2]
nhkd: spawn [katriac client_move_mouse motion 2153 718 46137347 3]
...
nhkd: spawn [katriac client_move_mouse motion 2153 715 46137347 11]
nhkd: spawn [katriac client_move_mouse motion 2153 715 46137347 12]
nhkd: spawn [katriac client_move_mouse motion 2153 714 46137347 13]
nhkd: spawn [katriac client_move_mouse up 2153 714 46137347]

katriawm benutzt das (noch?) nicht, aber es könnte nun zu alte Events einfach basierend auf der Seriennummer ignorieren.

(Wegen einer Design-Inkonsistenz ist katriawm eh gar nicht von diesem Reihenfolge-Problem betroffen. Aber das könnte man in diesem Zuge auch geradeziehen.)

xlocatemouse

Wie man am Screenshot von highcal oben sehen kann, benutze ich derzeit ein helles Farbschema für’s Terminal. Wenn man in der Sonne auf dem Balkon sitzt, ist es dann erstaunlich leicht, die Maus zu „verlieren“ und nicht wiederzufinden. Weil der Kontrast so mies ist, bringt Wackeln auch nichts.

xlocatemouse als Abhilfe:

xlocatemouse

Zu meiner Überraschung konnte ich kein fertiges Tool dieser Art finden. Ein paar Desktop-Environments haben sowas wohl, aber kein Standalone-Tool?

Elefanten

Art by Shanaka Dias
    _    _
   /=\""/=\
  (=(0_0 |=)__
   \_\ _/_/   )
     /_/   _  /\
snd |/ |\ || |
       ~ ~  ~

Source.

Im Englischen gibt es den schönen Ausdruck „the elephant in the room“, wofür es im Deutschen leider kein Äquivalent gibt. Gemeint ist das ganz Offensichtliche, was aber aus diversen Gründen ignoriert wird. In diesem Fall ist es sogar eine ganze Herde von Elefanten – da ich die Tiere aber sehr mag und nicht vertreiben will, widmen wir uns erstmal nur einem davon.

Ich schreibe immer noch neue Programme für X11. Es funktioniert, ich bin’s gewohnt, also bleibe ich dabei. Vielleicht wird es langsam Zeit, dass sich daran etwas ändert?

X11 hat wahnsinnig viele Altlasten und ist manchmal nicht freundlich im Umgang. Bei den Manpages fehlen oft wichtige Informationen wie „was bedeutet dieser Returncode eigentlich?“ Und so weiter.

X.Org soll angeblich ohnehin „im Maintenance-Mode“ sein, etwas ähnliches habe ich von Xenocara auf OpenBSD aber noch nicht gehört. Trotzdem verliert X.Org langsam an Bedeutung und das heißt, dass sich in der Linux-Welt Dinge ändern werden, was sich auch auf andere Systeme auswirken wird. Früher oder später werden die Toolkits ihr X11-Backend rauswerfen. Bis dahin ist es noch ein sehr weiter Weg, aber trotzdem.

Wayland. Ich hab’s lange ignoriert.

Was mich daran so sehr stört, ist, dass alles in eine Komponente zusammengeworfen wurde. Ich hatte mal versucht, einen ganz einfachen Compositor zu schreiben, aber das ist furchtbar viel Arbeit. Das will ich einfach nicht machen. Ich will auch eigentlich gar keinen Window-Manager schreiben, sondern einfach nur meine Fenster nach meinen Regeln frei verwalten können. Unter X11 ist der einfachste Weg, das zu tun, eben, einen WM zu schreiben.

Ich bin sehr hoffnungsvoll, was wlroots angeht. Es ist zwar noch recht jung, hat aber das Potential, der neue „Display-Server“ zu werden, damit man wieder seinen „Window-Manager“ schreiben kann.

Mal sehen. Ich sollte mir Wayland jedenfalls genauer anschauen. Einziges Problem ist Energie und Motivation. X11 funktioniert für mich hervorragend, nichts ist kaputt, nichts stürzt ab. Aus einer rein pragmatischen Sichtweise habe ich genau gar keine Motivation, irgendetwas zu ändern. Ich sollte also mehr über die Wayland-Interna lernen und mich dadurch überzeugen lassen, dass es besser ist und ich migrieren sollte. Hoffen wir mal, dass das so passiert.

Eine große Hürde ist noch, dass Wayland (noch?) nicht auf OpenBSD verfügbar ist. Zumindest weiß ich davon nichts. OpenBSD wird für mich immer wichtiger: Ich habe so im Gefühl, dass ich vielleicht zumindest manche meiner Desktop-Rechner irgendwann in den nächsten Jahren darauf umstelle. Wenn/falls das passiert, will ich aber nicht zu X11 zurückmigrieren.

Comments?