Some (Desktop) software development updates
The Qt path
As mentioned in the previous post, I wanted to give Qt a try to see if it handles the HTML problem better, than Flutter.
It took quite some effort to reach the UI polish that the Flutter version had but I eventually got there. Almost at least 😃.
The result was a bit mixed. Whilte it solved the webview issue way better than Flutter, the approach that Qt takes also has some drawbacks:
- The complete web engine gets bundled with the app (the engine and the Qt specific additions and integrations). Which is OK in this day and age but still I consider that a downside. To get a better idea: on macOS the installed application has around 450MB. The Flutter version has around 230MB.
- Performance: While the webview at least works on Linux its performance on macOS was way worse than in the Flutter version. I didn’t measure concrete timings but it takes longer to load the web content.
I also continued to experiment with the rendering performance on Linux with both - Flutter and Qt - and in the end both of them have a problem getting resized smoothly on Linux. After fine-tuning there is no visible difference any more between Qt and Flutter. Both are bad 😃.
Given this situation I decided to give the Flutter + webview another try. This time I went way deeper into the problem and solved the problem at its root: The Flutter engine and embedder.
The first problem was that Flutter’s Linux embedder had no proper way to place a native GTK WebView inside its scene. Our early integration let WebKit paint into the same drawing target as Flutter. With a long email on screen, the HTML could take over the window and the Flutter UI around it disappeared. Simply stopping that draw kept the UI, but left the email blank. A small test app with two WebViews helped us reproduce the problem without involving Proton or the mail reader.
We patched Flutter to pass the correct position of a platform view through to the embedder, then taught the Linux embedder to keep Flutter’s layers and the native WebViews in the right order. Each WebKit view now gets its own native drawing surface, clipped to the part of the message that is actually visible. On X11 that means a child window. The first version looked promising there, but on native Wayland the HTML was still blank. Wayland needed an explicit subsurface; once we added that, the same test showed both WebViews, the Flutter UI and an overlay together, even after resizing.
Long emails brought another surprise. The reader might lay out an email tens of thousands of pixels high, but WebKit only needs a viewport about as tall as the visible pane. We kept the full height for Flutter’s scrolling and limited the native WebView to that visible area. Then we had to make wheel events, text selection, focus and clicks reach the right side of the Flutter/WebKit boundary. This took quite a few patches, but it means we can use the real WebKitGTK engine on Linux without turning each email into a screenshot.
So finally it worked! Not as nice as on macOS but similar to the Qt version on Linux.
The patches are still a downstream solution for the Flutter version MailLama uses. The engine and Linux embedder changes deal with native views more generally; MailLama’s WebKit plugin and the way the mail reader scrolls are separate pieces. I would like to contribute the general parts back to Flutter, but first I need to split up the patch set, clean up the experimental code and test it beyond our particular app. I think that is worth the effort.
This experience brought me back to continue using Flutter for all my cross-platform (desktop) applications.
Lama-fication
I went to an Alpaca farm and we took a few Aplacas for a walk with the whole family. This was nice and fun. While doing that I weared by Lama basecap that I have created a while ago. The idea was that the Lama can be a family logo as it is very near to our last name (Lamers).
While reflecting that day and remembering the pain it is to come up with application names I had one idea: What if all my applications would pick up that lama theme. That would be cool, wouldn’t it?
I had some brainstorming with an AI agent and we came up with those names:
- CrossProton -> MailLama
- Mimameidr -> ProcessLama
- NorthSpline (a git client I’m working on) -> GitLama
- Nibluma (a note taking tablet app) -> NoteLama
- CrossVeil (a screenshot app I’m working on) -> ShotLama
Then I tasked Opus to do a full scale rebranding:
- folder name
- application id and name
- logo
- repository name
- landing page
For those kinds of tasks AI is gold! I think I would have just not done it by hand tbh. Or at least I would have just changed the name and the logo.
Then I took it to the next step and tasked Opus 5.5 to really rework all the webpages and make them nice, playful and have the lama very prominently on them.
I requested it to come up with funny animations and application specific lama behavior.
In my opinion the result is realy crazy good. You can look and judge for yourself but I would have never been able to achieve something remotely close to that level of quality and richness:
