Calamares 3.1.3 released

Calamares is an (Linux) installer framework. It’s an application with lots of pluggable modules to do system installation tasks (like partitioning, setting up users, and enabling encryption on filesystems) needed when installing Linux onto a computer system. There are modules written in C++ (with Qt), modules in Python, and modules in Python (with Qt). The middle bunch was, up until this release, untranslatable.

Calamares 3.1.2 was released yesterday, followed by a hotfix 3.1.3 (my bad), with new potentially translatable strings. I’ll admit that the last few strings were snuck in quite late, so translations are incomplete. This is no worse than they were, where the strings were entirely untranslatable. Expect more complete translations with 3.1.4, to be relased in two weeks time or so.

This is a medium-sized step for the accessibility of Calamares, now that more of the application is available in the user’s native language.

I’m also planning a much bigger accessibility step, which is adding screen reader support to the application. Actually, “adding” is probably the wrong word: I’ll stop agressively not supporting screen readers. That hostility towards screen readers comes from the setuid nature of Calamares (it’s messing around in filesystems and partitions and whatnot) and that hostility needs to end. Adaptive technologies should be usable also when installing a computer.

With that in mind, I will be going to Randa next month for this year’s Randa meeting, which has a focus on accessibility. The dot story explains the purpose of the meeting better than I can, and one of the comments presents exactly the challenge: turn off the monitor. Now boot the computer with CD in the drive, and install Linux. If Calamares can make that possible, then we’re helping everyone get Free Software.

To help the Randa meeting help everyone, consider making a donation, which helps to keep lights on in Randa (not the heating — we bring sleeping bags because it’s cold in the mountains, even in summer).

(I should note: Calamares isn’t a KDE project, although it is used by some Linux distro’s that have a KDE focus. It is also used by some Linux distro’s that focus on a Qt-free experience after installation. Calamares is an independent project, supported by Blue Systems. And yes, I do hope to install FreeBSD with Calamares at some point.)

QtWebKit on FreeBSD

Over at, there is an article on the coming WebKitGTK apocalypse. Michael Catanzaro has pointed out the effects of WebKit’s stalled development processes before, in 2016.

So here’s the state of WebKit on FreeBSD, from the KDE-FreeBSD perspective (and a little bit about the GTK ports, too).

  • Qt4 WebKit is doubly unmaintained; Qt4 is past its use-before date, and its WebKit hasn’t been meaningfully updated in years. It is also, unfortunately, the WebKit used in the only officially available KDE ports, so (e.g.) rekonq on FreeBSD is the KDE4 version. Its age shows by, among other things, not even rendering a bunch of current sites properly.
  • Qt5 WebKit port has been updated, just this weekend, to the annulen fork. That’s the “only a year and a half behind” state of WebKit for Qt5. The port has been updated to the alpha2 release of annulen, and should be a drop-in replacement for WebKit for all ports using WebKit from Qt5. There’s only 34 ports using Qt5-webkit, most of them KDE Applications (e.g. Calligra, which was updated to the KF5-version some time back).
  • Webkit1-gtk2 and -gtk3 look like they are unmaintained,
  • Webkit2-gtk3 looks like it is maintained and was recently updated to 2.16.6 (latest stable release).

So .. the situation is not particularly good, perhaps even grim for Qt4 / KDE4 users (similar to the situation for KDE4 users on Debian stable). The transition of KDE FreeBSD ports to Qt5 / Frameworks 5 / Plasma 5 and KDE Applications will improve things considerably, updating QtWebKit and providing QtWebEngine, both of which are far more up-to-date than what they are replacing.


At some point, the KDE4-era KDM is going to end up unmaintained. The preferred display or login manager for KDE Plasma 5 is SDDM, which is Qt-based, and QML-themeable. In Area51, the unofficial KDE-on-FreeBSD ports repository, we’ve been working on Plasma 5 and modern KDE Applications for quite some time. One of the parts of that is, naturally, SDDM.

There’s x11/sddm in the plasma5/ branch right now, with a half-dozen code patches which I’ll have to look in to for upstreaming. I decided to try building it against current official ports — that is, current Qt5 on FreeBSD — and using it to log in to my daily FreeBSD workstation. One that runs KDE4. That is immediately a good test, I think, of support for not-the-obvious-X11-environment for SDDM.

So the good news: it compiles, installs, and runs. We’ve added a few tweaks, and still need to figure out which packages should be responsible for adding .desktop files for each environment. SDDM now installs an xinitrc.desktop, for the most-basic case. Switching kdm_enable to sddm_enable in rc.conf is all you need.

The bad: some things aren’t there yet, like shutdown support. And, at least with my nVidia card, fonts can vanish from the login screen after switching vt’s.

The ugly: we really need to spend an hour or two on doing some branding material for SDDM / Plasma 5 / KDE Applications on FreeBSD. Basically slapping Beastie on everything. Graham has created some graphics bits, so we’ve got something, just not packaged nicely yet.

Speaking of the Good, the Bad, and the Ugly, I re-watched it recently, but now with the added interest of figuring out where in Tabernas or Rodalquilar it was; turns out the beach past the airport is also part of the desert scenes. And SDDM can soon be part of the FreeBSD scene.

QtWebEngine on FreeBSD

It’s been a long time coming ..

Tobias and Raphael pushed the button today to push QtWebEngine into FreeBSD ports. This has been a monumental effort, because the codebase is just .. ugh. Not meant for third-party consumption, let’s say. There are 76 patches needed to get it to compile at all. Lots of annoying changes to make, like explaining that pkg-config is not a Linux-only technology. Nor is NSS, or Mesa, while #include <linux/rtnetlink.h> is, in fact, Linux-only. Lots of patches can be shared with the Chromium browser, but it’s a terrible time-sink nonetheless.

This opens the way for some other ports to be updated — ports with QtWebEngine dependencies, like Luminance (an HDR-image-processing application).

The QtWebEngine parts have been in use for quite some time in the plasma5/ branch of Area51, so for users of the unofficial ports, this announcement is hardly news. Konqueror with QtWebEngine underneath is a fine and capable browser; my go-to if I have Plasma5 available at all on FreeBSD.

CMake 3.9 on FreeBSD

The KDE-FreeBSD team also maintains the CMake packages on FreeBSD — mostly because KDE was the first big consumer of CMake. The meta-buildsystem is now used by hundreds of packages on FreeBSD. We recently switched the backend — the build system that is generated by CMake — from make to ninja, which gives us small-but-measurable build-time improvements.

Now we’re working on the CMake 3.9 update, which was released a two weeks ago.

Re-building hundreds of packages that use CMake is always an interesting exercise, since it’s the kind of big-practical test that regular testing avoids (this reminds me that really, we should be doing this in the RC phase rather than after release, to help the CMake folks find stuff before a release is finalized). The interesting bits have to do with all the ways that people find to abuse CMakeLists and do weird stuff.

Three CMake things I noticed recently:

  • Checking if stderr is a tty (for instance, to produce pretty colorized CMake output when it is) changed between CMake 3.0 and 3.1. OK, that’s not a recent change, but me-asking-myself “wasn’t this colorized?” was recent. Not a bug, something to work around most likely.
  • Finding UI files and automatically processing them has changed slightly. It is possible to add search paths. Quoting from the release notes,

    A “CMAKE_AUTOUIC_SEARCH_PATHS” variable was introduced to allow “CMAKE_AUTOUIC” to search for “foo.ui” in more places than the vicinity of the file including “ui_foo.h”.

    This breaks projects that #include "path/to/ui_foo.h". Previously, CMake ignored the path and looked for the UI file in the same directory as the source including it. Now, it looks for the UI file at the given path. In some packages which pull weird shenanigans with include flags and UI file locations, this breaks. Bug filed, though I have come to the conclusion that “Don’t Do That Then” is the right response and we’ll have to patch the packages that do this.

  • A change in the way auto-MOC works has revealed a bug of sorts in either auto-RCC or the ninja backend generator; this breaks Digikam for us. The same problem can be triggered in earlier CMake versions by turning on auto-RCC. Since we end up with different build results between make and ninja (make build succeeds, ninja doesn’t), I’ve filed a bug for this too. We’re still looking at what ought to be done about it, though. In the meantime there’s a simple fix for Digikam, though I’m not sure what other packages may be affected.

Trawling through packages that use or support (much) older CMake versions make me appreciate how far CMake has come since, say, 2.7. Whenever I find a page and a half of convoluted code to figure out which compiler flags support a given C++ standard, I’m glad of newer approaches like set(CMAKE_CXX_STANDARD 17) and be done with it. But I can understand projects not chasing CMake releases all that closely; there is a maintainence cost after all.

Anyway, thanks to the CMake folks for being very responsive to bug reports, and for FreeBSD users, expect CMake 3.9 soon-ish — it depends a little on how it intersects with the other updates we are trying to do, where Plasma5 is a big thing happening right now.

Keyboard Layouts the way Sun Microsystems Intended Them

I am a long-time Sun Microsystems fan. So in the time that I worked on KDE 4 on OpenSolaris, I had a bunch of Sun hardware, including keyboards and mice. It’s always useful to have Stop-A available, even if the system the keyboard is attached to is not a SparcStation and doesn’t react to that gesture.

Screenshot of Keyboard KCMAnyway, I still use the Sun keyboard most of the time, but it is a decade old by now, and starting to show its age. And sometimes I use other hardware, like the KDE Slimbook, which has the control-key in the wrong place (next to the penguin, or meta-key). I have had a setxkbmap + xmodmap script that I have used since forever, but really that it a bit foolish: there are KDE settings to achieve the same thing.

So, to put Ctrl where it belongs (next to the letter A) and Caps-lock in the corner where a somewhat useless key belongs (next to the meta-key), use the KDE keyboard settings module: search for keyboard hardware in kickoff or krunner, then switch to the advanced tab, open up the Ctrl key position tree and put them in their place by checking swap ctrl and caps lock.

My muscle memory is much happier this way (it does adjust to different spacings of keys and the way the escape key is not all alone by itself, but the ctrtl key is important).