Status update March 2024

Sxmo

We continue to improve, to re-factorize, and to fix bugs as they come. Since October, we released 1.15.0 which include the hook unification. What it means is that we now have one “version” of the script hooks for all devices, which include the desktop mode, and the e-reader mode with the new Kobo Clara support. A lot of changes was required for that to land.

Also, since the latest Sway 1.9 release, I have dropped our sxmo-sway fork. A lot of discuss was needed on the Alpine packaging side to make this as smooth, transparent, and secure as possible. I tried to avoid the issues we had last time, when we moved to this fork.

Wvkbd and Bemenu Wayland optimizations

Since sometimes I am trying to minimize the cost, and the visual aspect of the first frame rendering. To make this short, it is currently difficult to render the first frame correctly, with the correct scale value. Before that point, bemenu and Wvkbd was blurry on the first frame. This was specially visible on a low-tech device as the Pinephone.

Also, Wvkbd adapt the layout, and the height dimension if it detects it is in a landscape mode. It means it was at first taking both of its needed space on the first frame. It was not elegant at all on a tiny screen as a smartphone, because both Wvkbd and other programs have to update their dimension two times while opening the keyboard when landscaped.

The problem is that to receive those data from the compositor, both of these programs have to create an initial Wayland surface without knowing anything about the current context. This also depends a lot on the compositor. Some of them would send output data first, some of them would wait for a surface to be created and assigned a role. The Wlroots scene API would eventually continue to change how Sway behave about this on the next release.

With my recent patches, and on Sway 1.9, both of these programs render correctly, pixel perfectly, and does not make the other programs to dance too much while landscaped or not. But this will continue to change over time, and releases. So I’ll continue to keep an eye on this.

Hare speak HTTP?

I really want to be able to use Hare to build things for the web. One of my plan is to write an IRC-v3 to less-good-chat-platform-as-Mattermost-or-Slack single user bridge. For this to happen, first we have to add HTTP support to a Hare library first. I sent some patches, and worked with Drew to push this topic forward. An initial hare-http server API should be merged in a close window. I am now working on a hare-ev HTTP support, because we can’t really use a blocking event loop in a real-world web service. What I need first is an easy way to scan the received UTF-8 buffer, while receiving it. At the moment there is no way to distinguish a matched token (an HTTP line), or the end of the current buffer.

Himitsu remembering consentement

Today I am still using my own pass implementation (based on age, and not GPG) as password manager. I’d like to move to Himitsu at some point, but some important features are needed for this to eventually happen:

• Synchronization between multiple devices
• Consentement remembering for some time

The first point could be mitigated with a Syncthing shared folder between device, I guess.

But there is currently no work-around for the second point. I have a lot of periodic scripts or programs that are configured to read password from my password manager. I don’t want to be prompted every fifteen minutes while synchronizing my emails, calendars, whatever. Ideally I want for Himitsu to prompt me one time for every script, and I would check a “don’t ask me again for those entries for a week” mark. That what I started to implement, and sent to the Himitsu mailing list. At the moment it isn’t persisted on disks, so it means it does not survive system reboot or daemon restarts yet. But I’ll work on this next!

Hope I do not forget something important… Well, enough for today!