As you probably have heard by now the lastest development versions of Plasma and KDE Frameworks require Qt6. This transition has been in the works for a few years by now, but it was only somewhat recently that we took the plunge and started relying on Qt6 exclusively for Plasma. Plasma 5.27 is the last Plasma 5 release and continues in bugfix-only mode.

For people who want to hack on Plasma features this raises the obvious question: How do I build Plasma 6 to hack on it?

Before diving into this, a word of warning: Current Plasma master is in no way “ready for production”. There are known-broken things and things may temporarily regress at any time. That said, the only way to get towards a stable thing is to dig in and fix things. So let’s see how to do that.

For this explanation I’m assuming you have build KDE software with kdesrc-build before. If not we have some extensive documentation for that. First you need at least Qt 6.4 installed. The usually best way to get that is from your distribution. If your distribution does not have Qt6 packaged yet please complain^Wtalk to them. CMake should complain about any missing Qt6 modules/development files, but make sure you have the qtpaths tool installed beforehand. It should be named something like qtpaths6 or qtpaths-qt6.

Now we need to teach kdesrc-build to build Plasma with the right configuration (git branches, CMake arguments etc) for building with Qt6. The easiest way to do that is by using a separate kdesrc-buildrc file. kdesrc-build comes with a sample Qt6 configuration file that you should use as a starting point. Replace the line include ~/kde6/usr/share/kdesrc-build/kf6-qt6-build-include with a path to your existing kdesrc-build installation. For me that would be include ~/kde/src/kdesrc-build/kf6-qt6-build-include. You can also apply other customizations that you usually do in your kdesrc-buildrc. Then save the file as e.g. ~/kde6/kdesrc-buildrc. This configuration will download, build, and install everything under ~/kde6. Currently it is very important to keep Qt5-based and Qt6-based builds separate since there will be conflicts between the installed files.

Now you can invoke kdesrc-build as usual, with one slight difference. Passing --rc-file=/home/user/kde6/kdesrc-buildrc will make it use the Qt6 configuration. If you omit the --rc-file argument it will use the old, Qt5-based configuration, so you can keep building Qt5- and Qt6-based stuff in parallel (but installed into different locations). Since kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc is a bit of a mouthful you might want to configure a shell alias like kdesrc-build6 for it.

Now you can do kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc workspace to build Plasma. Note that it’s expected that not all modules successfully build since not all of them are adjusted to Qt6 fully yet.

Once Plasma is build you want to log into the new session. To do that go to ~/kde6/build/plasma-workspace and run sudo ./login-sessions/install-sessions.sh once. Then you can select the new session at login in SDDM.

Now for some question that might be on your mind:

Q: Is it stable?

A: No, see above.

Q: When will it be stable?

A: Time will tell. It will be several more months before we can consider a Plasma 6 release.

Q: I tested it and found a problem, what should I do?

A: Report it to bugs.kde.org, and state that you are using Plasma master. Or try fixing it yourself.

Q: I want to work on a Plasma feature, what should I do?

A: Try developing it against Plasma master. If you find yourself blocked by anything please tell us.

Q: Does this apply to other KDE software as well?

A: Yes. Note that most applications allow building against Qt5 and Qt6 from the same branch though. And some apps aren’t ported to Qt6 at all.

Q: I did not understand a word of what you just said but I’d still like to help.

A: One way to help is by donating to KDE. Your donations help me have time to do things like working on Qt6 support or writing this blog post

After the recent release of KBibTeX 0.9.3.2 as the last release of the 0.9.x branch, it is now time to make a stable release of KBibTeX 0.10.0. Tar-balls are as usual available at KDE’s download mirrors. Some of the changes were documented more than two years ago in a pre-release (0.9.90), but here are the highlights taken from the ChangeLog:

• New online search: Semantic Scholar
• Migrating Inspire Hep to REST API
• Fixing and revamping ACM's Digital Library (a.k.a. ACM Portal) online search
• Refactoring NSA ADS to use official API
• Updating BibSearch code: cover page improved, preparing code for translations, adding progress bar
• Tabs in the entry editor can show short messages to use, e.g. in which tab DOIs or URLs are to be entered
• Fixing UI issues with ColorLabelWidget
• Using KRatingPainter instead of home-made StarRating's paint function
• Various improvements and refactoring when (PDF) files get associated with an entry
• Use Qt's own QOAuth1 class instead of external library QOAuth
• Having ICU as an optional dependency only, provide internal, static translation from Basic Multilingual Plane (BMP) characters to ASCII-only representations
• Greatly refactoring and modernizing CMakeLists.txt files, generation of camel-case headers, private/public linking to libraries, ...
• Updating translations (contributions by various authors)
• KDE Bug 421612: When suggesting entry ids, do not count ‘small words’
• KDE Bug 424033: Can't associate a file with a relative path without having the file copied
• KDE Bug 423976: When formatting IDs, non-word characters should be used as word separators
• KDE Bug 426856: File encoding is not always stored
• KDE Bug 379443: Slowdown when loading citation with many authors
• KDE Bug 433005: Cannot unselect entry list view columns in BibLaTeX mode
• KDE Bug 433084, KDE Bug 453455: Fixing crash when opening .bib file
• KDE Invent issue 1: Properly handling letter modifiers such as \c{e} instead of \ce
• Adding and extending numerous automated tests
• Numerous other fixes, clean-ups, refactoring, ...

Thank you to everyone who contributed. Happy compiling and packaging!

Working on the Nextcloud desktop client, I stumbled into a nasty little bug. If you tried to add or remove a user account, the app would often freeze for a while.

This was super annoying during testing, so I decided to look into it. Surprisingly this wasn’t a new bug I’d unwittingly introduced; tracing the source of the freeze led all the way down into QtKeychain, which is what the desktop client uses to store user credentials.

QtKeychain, like Qt itself, is great at making life easy for developers targeting multiple platforms as it abstracts away the different keychain/keyring/wallet implementations for the different platforms. Looking at the Objective-C++ code handling Apple platforms, QtKeychain’s different job classes called code using Keychain Services functions, as expected.

Fortunately the problem was pretty clear. All of the calls to the Keychain Services functions — SecItemUpdate, SecItemDelete, SecItemAdd, SecItemCopyMatching — block the calling thread. From Apple’s documentation:

SecItemUpdate blocks the calling thread, so it can cause your app’s UI to hang if called from the main thread. Instead, call SecItemUpdate from a background dispatch queue or async function.

This means that, when called on the main thread, doing any QtKeychain operations would lead to freezing the UI. Since this is not a problem on other platforms (that I know of!), it’s pretty easy to overlook this quirk of Keychain Services’ API. 

void DeletePasswordJobPrivate::scheduledStart()
{
    const NSDictionary *const query = @{
            (__bridge id) kSecClass: (__bridge id) kSecClassGenericPassword,
            (__bridge id) kSecAttrService: (__bridge NSString *) service.toCFString(),
            (__bridge id) kSecAttrAccount: (__bridge NSString *) key.toCFString(),
    };

    const OSStatus status = SecItemDelete((__bridge CFDictionaryRef) query);

    if (status == errSecSuccess) {
        q->;emitFinished();
    } else {
        const ErrorDescription error = ErrorDescription::fromStatus(status);
        q->;emitFinishedWithError(error.code, Job::tr("Could not remove private key from keystore: %1").arg(error.message));
    }
}

With use of Grand Central Dispatch, a fix was relatively straightforward. All that needed to be done was to call the offending functions from a different dispatch queue. I rewrote the Apple-specific keychain implementation in order to call the Keychain Services functions asynchronously from the global queue, passing an interface object that would call the relevant completion methods and signals on the read/write/delete QtKeychain jobs.

static void StartDeletePassword(const QString &service, const QString &key, AppleKeychainInterface * const interface)
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
        NSDictionary * const query = @{
            (__bridge NSString *)kSecClass: (__bridge NSString *)kSecClassGenericPassword,
            (__bridge NSString *)kSecAttrService: service.toNSString(),
            (__bridge NSString *)kSecAttrAccount: key.toNSString(),
        };

        const OSStatus status = SecItemDelete((__bridge CFDictionaryRef)query);

        if (status == errSecSuccess) {
            dispatch_async(dispatch_get_main_queue(), ^{
                [interface keychainTaskFinished];
                [interface release];
            });
        } else {
            NSString * const descriptiveErrorString = @"Could not remove private key from keystore";
            dispatch_async(dispatch_get_main_queue(), ^{
                [interface keychainTaskFinishedWithError:status descriptiveMessage:descriptiveErrorString];
                [interface release];
            });
        }
    });
}

Note that after these changes, your application will need to either use QGuiApplication or you will need to initialise NSApplication yourself if you use QCoreApplication.

Testing the changes with a fresh build of QtKeychain, I was happy to see the freezes are now gone in the Nextcloud desktop client. 🙂

Thanks to Frank Osterfeld for reviewing the pull request!

KBibTeX 0.9.3.2 got released, tar-balls are available at KDE’s download mirrors. This is the last release of the 0.9.x branch. Next is 0.10, where I will prepare release candidate tar-balls in the next few days and hopefully we will see a final release 0.10.0 this Spring.

A number of issues got fixed, including but not limited to:

• Bugs 463398, 459150, 464607, and 464606.
• Various online searches got revamped and should work again.
• Building against newer Qt versions (thanks to Albert Astals Cid)

See the full ChangeLog for all the details.

Some spoilers about what is happening in the ‘master’ branch: I have been working on an exporter to Microsoft Word’s bibliography XML. Writing scientific manuscripts with references in Word is a painful experience, but this exporter allows you to continue to use your favorite BibTeX editor even under dire circumstances.

Dear digiKam fans and users,

After three months of active maintenance and other bugs triage, the digiKam team is proud to present version 7.10.0 of its open source digital photo manager.

See below the list of most important features coming with this release.

Bundles Internal Component Updates

As with the previous releases, we take care about upgrading the internal components from the Bundles. Microsoft Windows Installer, Apple macOS Package, and Linux AppImage binaries now hosts:

There has been some recent discussions about how KDE applications (or Qt apps in general) should look and feel like outside of the Plasma desktop, particularly in a GNOME environment.

During this discussion I noticed two major disconnects between the involved parties. One of them is technical in nature, where (understandably) not everyone involved has deep knowledge about how Qt and KDE apps work. The other one is cultural in nature, where there’s opposing views about who gets to decide how an application should look and feel like on a given platform.

I can’t do much about the cultural issue, but I can help the conversation by giving some much needed overview of how any of this works on a technical level. Everyone being on the same page technically could help foster a more productive conversation about this complex topic.

First of all it’s important to note that Qt to its core is an abstraction across various plaforms (most important here are Linux, Windows, and macOS, but also to some degree Android and iOS). Whenever possible Qt tries to use the platform’s native facilities to do anything, whether that’s rendering, file dialogs, widget styles etc. This becomes somewhat messy when you consider that “Linux” isn’t exactly a single, well-defined “platform”. Qt does usually have non-native fallbacks for things like file dialogs and widget styles, but they aren’t necessarily something you want a user to have to see. It’s also important to mention that Qt has two somewhat competing ways of defining UIs, the traditional QtWidgets, and the more recent QtQuick/QML.

There are several somewhat independent pieces involved in how a Qt application looks and feels. Jan Grulich already talked about some of them in the context of GNOME and QGnomePlatform, but there are also things specific to KDE applications that aren’t mentioned.

The first piece is the “Qt Platform Theme (QPT)”. Despite the name it doesn’t have much to do with the visual style. It is responsible for applying settings from the platforms. This for example includes font settings, the double click interval, or whether a file should be openend on single or double click. It also defines how standard dialogs look like, most importantly the file picker dialog, but also dialogs like a color picker. Third, it defines the color palette (QPalette) the application is using. More on that later. Qt itself ships platform themes for non-Linux platforms as well as somewhat generic Linux platform themes for GNOME and Plasma. Notable out-of-tree plugin exist, like plasma-integration which you are using right now if you are on Plasma, the aforementioned QGnomePlatform targeted towards GNOME (and to some degree similar environments), and qt5ct, which isn’t aligned to a specific environment and provides generic control over platformtheme things.

The second, and perhaps most well-known, knob is the widgets style (also called QStyle). It controls the majority of the appearance of a QtWidgets application. Well-known examples include Breeze (the current Plasma default), Oxygen (the KDE4-default), adwaita-qt, as well as built-in styles for Windows/macOS. Qt also comes with a built-in Fusion style. QStyles are implemented using C++ plugins. Whenever the app needs to render some piece of UI, e.g. a button, it defers that to the style plugin. Some style, like e.g. Windows then use platform native APIs to render widgets, others like Breeze draw the widgets from scratch. Application developers can also include custom styles for complete control over the appearance.

The third important concept is QPalette. A QPalette is a set of colors used to draw UI elements. The palette is defined by the platform theme(!). For example Plasma uses this to apply the color scheme set in System Settings. QGnomePlatform uses it to apply Adwaita-like colors. The selected QStyle may (or may not!) use this palette when drawing controls. The application developer can also manually query colors from the palette for drawing custom widgets while still respecting the platform’s wanted colors. A platform theme may only offer a single palette this way, or include light and dark variants, or allow the user to configure arbitrary color sets (like we do on Plasma). It is also possible for application developers to override the system-provided palette, for example to offer an in-app dark mode switch.

For applications using QML there is another relevant component: The Qt Quick Controls 2 Style. For reasons I’m not going to go into QtQuick Controls don’t use QStyle for their styling. Instead they come with their own stying system, which is itself based on QML. In Qt5 QML apps only have a very basic and broken default theme that should never be used. In Qt6 they use Fusion by default.

These are the relevant knobs every Qt app has. Some app developers choose to use them to control the appearance of their apps themselves, but many others leave it to the environment to apply a suitable look and feel. Furthermore, there are some relevant KDE-additions to this that are important to understand.

One such addition is KColorScheme. You can think of KColorScheme as a superset of QPalette, i.e. it provides additonal color roles and thus finer-grained control over colors. When changing the Colors setting in Plasma’s System Settings you are picking a color scheme. This gets applied to QPalette via the plasma-integration QPT, but can also be queried directly by the application developer for custom painting. Contrary to QPalette a KColorScheme is not porgrammatically filled based on plaform values (that happens only on Plasma), but it is a static, textual list of colors. Here we have the first problem for running KDE applications under e.g. GNOME. When running a KDE app on GNOME QGnomePlatform will apply Adwaita colors using QPalette. However, this does not affect colors the application directly pulls from KColorScheme, which unless explicitly configured has a default that resembles Breeze. This means we get mixtures of two different color sets, giving unpleasant results. This is especially noticeable when using a dark system theme combined with the light default colors from KColorScheme.

How do we solve this? Well, I’ve been banging my head against that problem for a while. Short of removing the concept of KColorScheme entirely I see two realistic options, not necessarily mutually exclusive. QGnomePlatform could create a KColorScheme definition with Adwaita-like colors and apply that to the application. If exuted correctly it would likely give very good results, but obviously only on platforms that use QGnomePlatform. The other option would be to programmatically derive a KColorScheme definition from a QPalette, which is likely much harder because KColorScheme is a superset of QPalette, but it would be a generic solution for all platforms.

The second noteworthy thing for KDE applications affects QML apps in particular. I’ve mentioned that QML has a separate theming system compared to QtWidgets. Because maintaining two style definitions for different systems is no joy KDE maintains a “hack” around this. qqc2-desktop-style implements a Qt Quick Controls style that fetches style information from a QStyle, which means all the existing QStyles out there keep working for QML apps. It works amazingly well, until it doesn’t. One of the shortcomings of this approach is that qqc2-desktop-style internally heavily relies on KColorScheme, which makes the aforementioned mismatch between QPalette and KColorScheme much more prominent. Possible solutions are the same as mentioned before.

I hope this gives some much needed overview over technology and terminology of involved components and helps with a productive way forward with addressing the problems we have. You are welcome to join this discussion. There’s some other relevant things to talk about, like icon loading, theming, and rendering, but that’s for another day.

We're excited to announce the release of Glaxnimate 0.5.3! This update includes a number of new features, bug fixes, and improvements to the user experience.

Editing

Glaxnimate 0.5.3 introduces several new editing features:

There's a new keyframe preset called "Fast" that basically has the reverse effect of "Ease".

Additionally, this release adds support for conical gradients.

Users can now select the first Bezier node from the node's context menu.

Version 0.5.2 introduced the ability to animate along a path, 0.5.3 makes this easier as now there's a new context menu entry for position properties showing a dialog to select a shape to follow.

User experience

In addition to editing improvements, Glaxnimate 0.5.3 includes several UI enhancements. We've made color values in tree views more visually appealing, and removed extra items from the "Move To" dialog.

Changing fill, stroke, and gradient properties now applies to the whole selection rather than the last selected object.

We've also revamped the context menu for properties, making them consistent between the timeline and the canvas.

Editing tools are more forgiving now when you release modifier keys before finishing the shape.

Users can now choose whether the timeline scrolls vertically or horizontally without modifiers, and we've added new layout presets to better accommodate a variety of screen sizes.

File Formats

This release also includes updates to Glaxnimate's import and export functionality.

The main new feature here is the ability to import and export Android Vector Drawables, the animation format used when making animated icons for Android.

We've also fixed various issues with the SVG parser, improving support for animated paths.

Opening raster images now uses the file basename as layer name, and we've resolved a bug affecting plugin export.

Bug Fixes

Finally, Glaxnimate 0.5.3 includes a number of bug fixes. We've addressed an issue with layers created by drawing tools not having an end frame, and fixed several other small bugs affecting the user experience.

We encourage all users to upgrade to Glaxnimate 0.5.3 to take advantage of these new features and improvements. You can download the latest version of Glaxnimate from the download page.

It has been many years that I have provided up-to-date builds of KDE/Plasma for Debian stable, testing, unstable. It is now more than a year that I don’t use Debian anymore. Time to send this off.

As already mentioned in some comments to various blog posts here, I will not invest more work into the current repositories. I invite anyone with interest in continuing the work to contact me. I will also write up a short howto guide on what I generally did and how I worked with this amount of packages.

I feel sad about leaving this behind, but also relieved from the amount of work, not to speak of the insults (“You are a Nazi” etc) I often get from the Debian side. I also feel sorry for all of you who have relied on these packages for long time, have given valuable feedback and helpful comments.

It was a nice and long run.

So long, and thanks for all the fish.

Precisely one month ago I joined KDE e.V., the non-profit organization behind KDE, as Software Platform Engineer. This is part of three positions in KDE’s “Make a living” initiative.

The exact scope of this position is a bit vague. I like to describe it as “Taking care of everything needed so that people can build and enjoy awesome software”. A large part of that is taking care of foundational libraries such as Qt and KDE Frameworks, but it can be really anything that helps people do awesome things. This is pretty much what I’ve been doing as a volunteer for the last couple of years anyway.

So what have I been up to this past month? A lot, but also not a lot that’s worth mentioning individually right now. As you probably know we are heading full steam towards using Qt6 for all our products. This is something that started almost four years ago (and I’ve been involved from the start) and is growing ever more closely to being finished. Last week we switched Plasma master to use Qt6 exclusively, completing an important milestone for the whole transition. This involved a ton of small to medium-sized changes and fixes across the stack.

Instead of listing all the changes I have done as part of that let’s focus on the outcome instead: I’m typing this post running on a full Plasma session running against Qt6. There are still some rough edges, but overall it’s quite usable already. Definitely enough to get involved and hack on it. I’d show you a screenshot, but that would be pretty boring, it looks exactly the same as before!

So what does the future hold? The transition towards Qt6/KF6 is going to stay my focus for a while, but once that settles down I’m going to focus on other areas of our software platform eventually. If you have ideas for what it would make sense for me to focus on please get in touch.

This position is enabled and financed by KDE e.V.. To allow me to keep this position in the long term (and perhaps even hire additional people) please consider donating to KDE e.V.

I was first introduced to Linux when my outdated computer could not run Windows anymore. I had previously heard some information about LINUX while surfing the internet, but my initial impression was that it was highly sophisticated and exclusively for programmers or mainly hackers :). I finally started using Linux Mint, and was moved by how quick and configurable it was 🤩.

After a few distro-hopps, I finally settled for KDE Neon being amazed by how easily customizable it was ❣️

Motivation for applying to sok’23

I was very much content with KDE plasma but I always found some minor annoying bugs here and there, it was also around this time I got started with programming and was looking into ways to get better at it, so I decided that I would contribute to KDE 😇, and like every other beginner, I didn’t know how to navigate through such large repositories of KDE. I also learned about the Season of KDE program, which assists in onboarding new contributors for KDE, so I decided to apply.

My Project

My project for SOK’23 is improving the accessibility of Tokodon by writing appium tests. My project involves two parts: the first one is making Tokodon work without internet connection so that it is ready for tests and then the second part is writing GUI tests to improve accessibility. You can find my full project proposal SoK Proposal for Tokodon.

Work done so far🤗

Week 1-2:

In my first week, I researched how I would run Tokodon without network connectivity. I tried to reverse engineer the existing unit-tests, and created a new start file offline-main.cpp, and by the end of the second week, I could start Tokodon without network connectivity with some broken UI.

Week 3-4:

The next step was writing appium test for the search functionality. For this, I first fixed the broken search UI by reversing the already written unit-test for search and following which I wrote my first test for testing the GUI of search. The final result is shown in the gif below:

Week 5-6:

In these weeks I, with the help of the maintainers of Tokodon, fixed the breaking pipelines of tokodon-offline and also wrote another appium test for testing different types of timeline statuses.

What I will be doing in the upcoming weeks

In the upcoming weeks I plan to add more appium tests and fix broken UI elements in tokodon-offline.