blog · git · desktop · images · contact


highcal, nhkd, xlocatemouse, and some elephants

2020-05-21

highcal (and “be”)

gitodo was a to-do tool I wrote at the end of 2010. It has seen many changes. At first, it was a shell script that also worked on msysgit, because I had to use that at the time. It was later rewritten in Ruby as an experiment. I wanted to learn more about that language.

Let me put it this way: Ruby and I are not compatible. My code ended up looking a bit like Python anyway. I don’t want to ramble about Ruby, so we’ll leave it at that.

gitodo was replaced by be a while ago. That’s a very short shell script, not compatible with gitodo, fewer features – but it does what I need.

The gitodo project also came with a calendar program, highcal. It can highlight dates:

highcal

One major issue with the original highcal was performance. The first run takes about 0.2 seconds on my machine, later runs (when everything is cached) a little more than 0.05 seconds. That’s noticeable. It’s annoying. Put pluntly, it’s just the standard Ruby overhead:

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

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

highcal is now rewritten in C. I’m very lazy, so this version can only work on contemporary dates.

nano hot key daemon – nhkd

Back when I used dwm, I configured all global hotkeys directly in dwm. Downside is, you have to recompile and restart dwm for changes to take effect. That is one of the reasons why katriawm has no builtin key handling. It instead relies on external programs, such as sxhkd.

Shortly after I’ve written katriawm, some features got removed from sxhkd that I relied on. I was since stuck on version 0.5.5. Recently, sxhkd stopped compiling with GCC 10. I’m sure this will be fixed soon, but it would mean I would have to backport those changes to 0.5.5. Meh.

Instead, I put together nhkd. It uses code from dwm, but also extends upon it a bit. It’s called “nano”, because it’s really short and limited in functionality.

There is one particular problem with sxhkd 0.5.5: You can bind to mouse motion events, but there is no ordering. Click, drag, release – all the motion events during drag are individual processes and their order is virtually randomized. Modern computers don’t have a problem with all the processes, but the ordering is an issue. That’s why this was removed from sxhkd.

nhkd works around the issue by appending a serial number to the commands launched by motion events. Looks like this ($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 does not make use of this (yet?), but it could now simply discard events with an old serial number.

(Due to a design inconsistency, katriawm is not affected by the entire issue at the moment. But this could be improved now.)

xlocatemouse

As you can tell by the highcal screenshot above, I’m currently using a bright color scheme in my terminal. When sitting in the sun on my balcony, it is surprisingly easy to lose track of the mouse position. Due to the terrible contrast, wiggling it doesn’t help.

Enter xlocatemouse:

xlocatemouse

To my surprise, I couldn’t find an existing program that does that. Some desktop environments have this feature, but no standalone tool?

Elephants

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

Source.

Let’s quickly talk about the elephant in the room. Actually, there’s an entire herd of them, but I really like those animals and don’t want to chase them away, so maybe we’ll talk about the other ones some other time.

I keep writing new programs for X11. It works, it’s what I’m used to, so I keep using it. Maybe it’s time for that to change?

X11 has a ton of legacy and it’s sometimes not pleasent to work with. The manpages often lack important information like “what does the return code of this function mean?” And so on.

X.Org is supposedly “in maintenance mode” anyway, but I haven’t heard such a thing about Xenocara in OpenBSD. But with X.Org losing importance now, things are bound to change in the Linux world and this will affect other operating systems as well. Sooner or later, toolkits will drop their X11 backend. That’s a long way down the road, but still.

Wayland. I have ignored it for a long time.

The one thing that really annoys me about it is that everything is lumped together in one component. I once tried to write a very simple compositor, but this is a hell lot of work. I don’t want to do that. I don’t even want to write a window manager, I just want to be free to organize all windows exactly the way I want to. The best way to do that on X11 is to write your own WM.

I have high hopes for wlroots. It’s still relatively young, but this has the potential to be the new “display server”, so you can write your own “window manager” again.

We’ll see. I should look more into Wayland. Only problem is energy and motivation. X11 works really well for me, nothing is broken, nothing crashes. From a pragmatic point of view, I have zero motivation to change anything. I should learn more about the internals of Wayland and get convinced that, yes, it’s much better, I should migrate. Let’s hope that happens.

One big obstacle is that Wayland is not (yet?) available on OpenBSD. At least not that I know of. OpenBSD is getting more and more important to me: I have a feeling that I might be switching some of my workstations to it at some point in the next few years. When/if that happens, I don’t want to migrate back to X11.

Comments?