Status update February 2026

Hey there! 4 months since last time? But I wrote in between! Let’s start.

hare-lex, hare-template #

I ended the last year with something I’m really proud of. hare-lex and hare-template provides really good tools for Hare users. hare-lex is based on good graph theory science, and can cover multiple use-cases. And hare-template finally a better templating system than strings::template. I wrote dedicated articles on those subjects, so I keep it short here.

Sxmo #

Sxmo 1.18.0 and 1.18.1 was something big. We added support for two additional window managers (i3 and River). As usual this come with refactoring, and usage of more upstream approaches to talk with compositors. Ultimately this means we use more and more existing standards.

The development cycle of Sxmo tends to slow down. We don’t see massive overhaul that often anymore. This is really cool because this gives me more time to works on other stuff. The submitted patches seem to not get stucked for that long.

Wvkbd #

Wvkbd adapts its height and the layout it uses depending on the available screen geometry. The problem was how to determine this available geometry. We render an initial frame, with the sanest default, and then we eventually flip. This may cause a visual glitch, and cause a re-rendering of the environent top-level surfaces. We also encounter a similar situation with Bemenu.

I came to see if the Wayland folks had an idea on how to solve this problem. After some exchanges, a correct solution has been found. The best approach is to start by commiting a layer-shell surface taking the whole available space. An invisible surface that has no visual impact, just that gather the available space. Then we can create the keyboard using the correct initial information.

This Wvkbd fix has been applied upstream, and released. A bemenu merge request is also open to do the same thing.

hare-ev #

Hare has been released recently, and so are the external libraries. This means the hare-ev overhaul changes had to be applied on lot of projects I made with it. I tried to apply breaking changes as they come, but this prevents the projects to be released in between of Hare cycles. I should probably avoid doing that, but that dilute the work over time, and limit the rush after releases.

hare-streams #

When working on hare-template I wrote streams::prefix, a general purpose line prefixer stream. With recent hare-ev changes, I also worked on some streams::ring, a ring buffer to simplify writev buffer management.

Now that I have two of this kind, I finally made a repository for those boys! hare-streams is a toolsuite providing general purpose stream implementations. Feels free to submit your owns, if you think they serve a general enough purpose.

splitter #

Additionnaly to fixing I/O communication issues on the IPC, I implemented fractional scaling support to hari. With the latests releases, Splitter should now look even better! I also took time to chase memory leaks, and other design issues. At the moment the aports merge request is waiting for a qbe fix, but I’ll backport it when it lands.

sharetcp #

CW: sexualized discuss

We bought new toys with my partner, and so I was about to start using intiface-central again. A concern we had is that taking control over distant devices is still something barely not available. The easiest way would be to somehow tunnel our locally available TCP server to the other one.

I started working on sharetcp, another Hare hare-ev based solution. Basically this allows the subscriber side to mirror a TCP server from the provider one. A middleman server act as a relay.

This tool should absolutely not be used to transfer private data! There is no end-to-end encryption at all. The bytes are passed literally. But for the purpose of websocket frames containing toys control commands…

This was a really fun projects, and I had to find new ways to synchronize I/O buffered communications. I succeed using exclusively fixed size buffers, by preventing any read the system could not handle immediately. This makes this solution very cheap to host and use, but not very for large transfers.

hare-buttplug #

CW: sexualized discuss

Now that I have a good enough way to share the sockets, why not writing actual clients? For that I first need a library to encode and decode protocol messages, and to abstract a bit the communication burden.

I started hare-buttplug for that! The project is still very experimental. I waited for the recent v4.0 buttplug spec to be released, but now I have to wait for intiface-central v3.0 to be made available on Alpine Linux. But hopefully most of the hardest work is done, and I should be able to start writing actual clients with it.

future? #

I found a day-job I hopefully could invest myself more completely. Next monday I start working for a worker cooperative. Hopefully owning my own means of production in this capitalist world will mitigate my dissonances between my needs, and my values.