Skip to content

Pondering Qt

Wednesday, 12 March 2025 | Kai Uwe Broulik

Qt Contributor’s Summit 2025 is taking place in Munich in May. Unfortunately, I won’t be able to make it this year, so let’s talk about some of my recent contributions to our favorite cross-platform UI toolkit.

KWrite (Text editor) window displaying a snippet of C++ code. Context menu over its right scroll bar containing the standard Qt options (Scroll here, Top, Bottom, Page Up/Down, Scroll Up/Down) and new KWrite-specific entries (Show scrollbar marks, show scorllbar mini-map)
KWrite with quick access to its scrollbar settings

A couple of years ago I added a context menu to the line number bar in KWrite and Kate. Rather than having to go to the menu to toggle automatic line breaks or bookmarks, those options were now accessible from the context menu. I’ve always wanted to do the same to the scrollbar and have a mini-map option there. However, it wasn’t possible to extend the default context menu and I didn’t want to re-implement all of its Up/Down/Pg Up/Pg Down/etc logic. I therefore added a QScrollBar::createStandardContextMenu method similar to what QLineEdit has. As the name implies, it builds the regular context menu and hands it to you, so you can add your own actions to it.

Speaking of menus, I uplifted SH_Menu_SelectionWrap that decides whether menu selection wraps around when using the arrow keys from QStyle to QStyleHints. This allows Qt Quick Controls Menu to behave the same as QMenu. This behavior is off by default on macOS, for instance, and our own Qt Quick Controls 2 Desktop Style currently handles keyboard input itself to implement wrapping.

I’ve talked about it before that I sometimes just fire up a profiler and look at application startup performance. That’s while working on KWrite I noticed that it was spending a good amount of time parsing the shared-mime-info database. It’s basically a huge XML file containing information about all file types there are and how to detect them, either by file extension or by magic bytes within. Now, why would it even load that database when opening a blank new document?

There’s several places where KWrite and the underlying KTextEditor Framework need to know the type of a viewed file: to load the correct syntax highlighter, display the correct file icon in the tab bar and recent documents list, and so on. When the file type isn’t already known it tries to guess from its contents. Qt caches the database of course but the first one to create a QMimeDatabase triggers a load. However, none of this really matters for an empty document so it now assumes an empty document be of type text/plain. The correct type is actually application/x-zerosize but that’s really not what you want here.

Global Shortcuts settings, shortcut “Switch to next keyboard layout”, default Meta+Alt+K and a custom shortcut “Keyboard” pointed at by the mouse cursor
Using the “Keyboard” key to switch keyboard layouts, eh?

My trusty ThinkPad has a “keyboard key” (Fn+F11) which under Windows supposedly opens some keyboard settings page. For the longest time, I thought it just wasn’t supported under Linux because I couldn’t create a global shortcut with it. Recently I noticed in KWin’s Debug Console that it did in fact recognize the key. Turns out Qt just didn’t have a corresponding Qt::Key. Starting from Qt 6.10 there will be a new Qt::Key_Keyboard value.

Qt Wayland Client

Since last time I talked about Qt Wayland, I have done a few more optimizations to its SHM (Shared Memory) backing store. It’s the canvas that Qt provides to software-rendered applications for drawing their user interface.

I finally merged support for scrolling the backing store. This lets an application, such as a text editor or terminal emulator, optimize scrolling through a view by merely moving the pixels and filling in only the small gap that’s now left. Unfortunately, this optimization cannot be provided when using fractional scaling because there’s no integer number of pixels we can just move up or down.

Furthermore, Qt Wayland no longer uses a backing store with alpha channel if the window didn’t request one. Most toplevel application windows are opaque after all. It doesn’t really matter from the compositor’s POV since a wl_surface can carry an “opaque region” that indicates what part of the window is actually opaque and Qt sets it accordingly. ARGB32 and RGB32 are the same in-memory size, too. Nevertheless, not using an alpha channel lets Qt skip certain operations, such as clearing the paint area before starting to draw.

While investigating a performance problem in animations under Wayland, I noticed that StackView’s new pushItem methods didn’t use any animation by default. As part of the effort to give QML tooling, such as qmlcachegen and qmllint, more context, many generic methods were supplemented by proper overloads. For example, StackView.push(var) takes either an Item, a Component, or a URL but you could call it with anything and that’s why it has to be invoked dynamically. StackView.pushItem on the other hand is declared three times with an explicit type which allows to generate more efficient code.

It didn’t make much sense that they would behave differently, of course. Indeed online documentation clearly said “If no operation is provided, PushTransition will be used.” We concluded it was a copy-paste mistake and I changed this for Qt 6.8.3, even though it’s technically a behavior change.

I’ll be jealous of your Weißwurstfrühstück in Munich and am looking forward to attending Qt Contributor’s Summit again in 2026!