_Status update, April 2022

_The Very Opinionated Mail Interaction Toolkit

I spent a good part of the last month learning Rust. Not really from scratch, but I finally found a good project to tackle to motivate me through the phase of initial frustration, which I’ve been in before. Rust has a pretty steep learning curve, and my code is probably still not great, but I do want to get to the point where I can at least contribute simple fixes or improvements to Rust projects of moderate complexity. Anyways, to not blow up the status update I dedicated a separate blog post to the project. That post and the project page have a lot of details, so do take a look!

_The state of GUI programming

As much as I like my terminal, I really appreciate a good GUI, and I often whish there were more desktop apps available as an alternative to the current trend of running everything in the browser. A good GUI can still be keyboard-centric (see e.g. Qutebrowser or visurf), and the information density you can convey in a good GUI is just unparalleled. Plus, with Linux phones becoming more of a thing, GUIs (though of a very different type) will gain new importance.

As such, another good chunk of this month was spent researching the current state of GUI programming. The executive summary is, as always, “it’s complicated”. I was mainly looking for something that allows for pleasant text rendering, including layout and styling. Say what you will about HTML and CSS, but it really is very good at that job. I sort of started to understand why so many applications are built on Electron and friends these days.

However, that’s not an option for me. So I looked into GTK, first GTK4, then GTK3. I failed to get the layout system to do what I wanted (a single widget, taking up all space in the window, up to a certain maximum width, above which the widget should be centered in the window). I found the documentation to be not great, especially on layout managers.

A disclaimer might be in order: a long time ago, I used to be a KDE contributor, hence I’ve used Qt a lot. This was Qt3, some Qt4. But still. I might have approached the whole thing with the wrong mental model. However, I stand to the claim that it is much easier to build such a mental model from the Qt documentation than it is from the GTK documentation.

At this point, I felt the breath of the dark side in my neck and considered using web views. However, the programmatic interaction with web views (at least in GTK) is not very straight-forward. It felt clumsy pretty quickly, and I was relieved I wouldn’t be inventing a new Electron.

I also looked into immediate mode GUIs for a moment, as I really like the appearance of e.g. Lagrange. However, always remember in such a situation: text rendering hates you. It really does. And even if you’ve gotten the text rendering working, you still need to implement the text interaction: selection, accessibility, etc. Lagrange has at least the rendering and selection part going, but it’s a massive code base. The relevant parts are very tightly coupled to the whole system. It didn’t seem very promising to try to start ripping it out.

And so, I ended up in a familiar place: Qt. Qt has been the subject of much debate ever since I first came across it. That is because it has a dual licensing approach, and the company behind it has clear commercial interests. While this has led to some rather ”interesting” developments, the company has stood by their commitment to keeping the core of Qt open source for many years.

I find Qt well-designed and extremely well-documented. There are pretty good Rust bindings. I was able to write a simple example application in a very short time and with very little code. Styling the application with CSS snippets is very convenient. The one thing I haven’t tested yet is using a Qt GUI on a phone, but since e.g. KDE’s Plasma Mobile is based on Qt, I don’t expect any problems.

I’ll put the source code for the little example app up, maybe someone can prove me wrong about GTK after all. I wouldn’t mind!

_The forge

The forge development also picked up some steam again. There were some issues around PGP keys, that turned out to be quite the rabbit hole. For once, we discovered a panic in of the libraries we use. At Sourcehut, we consider our dependencies to be our responsibility, too. The fixed version is already deployed on Sourcehut, and the Go email sending code should safely fall back to unencrypted mail if the encryption fails. However, there is more. Due to the Go/Python split, sending emails can happen in multiple code paths. We are working on unifying all PGP handling in a single (Go) code path, but it will take some time.

While Adnan is doing most of the GraphQL-related work at the moment, I did give some loving to the pages.sr.ht GraphQL setup. I have to give yet another shout-out to hut! It is now possible to use it against a local development environment. Your config would look something like this:

instance "local" {
	access-token "..."
	meta {
		origin "http://localhost:5100"
	}
	pages {
		origin "http://localhost:5112"
	}
}

Using this setup for testing, I created a patch to support setting Cache-Control headers for individual files on pages.sr.ht. This has the potential to make Sourcehut sites even snappier, but as a former infrastructure engineer that was involved in CDN operations, I have to caution you: caching something cannot be easily undone, so think twice (and as always, RTFM) before setting a big ol’ max-age!