We have started the release process for the next feature release of Krita today! This release is the culmination of years of hard work. From the same codebase, we're building both Krita 5.3, based on Qt5, and Krita 6.0.0. based on Qt6. Krita 6 is not yet available for Android or ChromeOS because Qt6 is unstable on those platforms.

Highlights

To learn about everything that has changed, check the release notes!

Text Object

The text object has been completely rewritten, as have all the tools to handle text. You can now edit text on the canvas, make text wrap inside vector shapes and put text on a vector path. We support most if not all scripts fully as well.

A variety of technical blog posts were written on the topic: Fonts, Open Type, Font Metrics, various other properties, Text in Shape and Type Setting Mode.

Wayland Color Management Support

A Krita 6-only feature, on Linux, we now support Wayland color management support when Krita runs in native Wayland mode. Note that the only officially supported wayland compositor is KWin. If you use another compositor and find an issue, test with kwin first whether that issue reproducible.

Tools

There is a completely new tool: a knife tool for vector objects, for merging and splitting vector objects. This is extremely handle when creating comic page layouts. Other tools have been extended or have improved performance. For instance, the freehand drawing tool has a pixel-art stabilizer and the liquify transform tool is much faster.

Assistants

Configuring assistants has become easier and there's a new curve-linear perspective assistant.

Filters

There are new filters: propagate colors and color overlay mask. All blending modes have been checked for correctness when working in HDR.

Dockers

The recorder docker now can capture in real time. Dockers can be added to the popup palette.

Brush Engines

Among other improvements, the pattern option has been extended with a soft texturing mode.

File Formats

There is support for a new file format, Radiance RGBE. Additionally, JPEG-XL support has been improved a lot, just in time for Googles volte-face on JPEG-XL support. And... Text objects in PhotoShop files now be loaded as text! You can save text to PSD as well, but only in a limited way.

Python Plugin API

The Python plugin API has been extended with an API for generating brush strokes, new user interface objects and new methods for existing classes. There are also new python plugins.

Krita 5.3 Downloads

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

• 64 bits Windows Installer: krita-5.3.0-beta1-setup.exe
• Portable 64 bits Windows: krita-5.3.0-beta1.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

Note: starting with 5.2.11, the minimum supported version of Ubuntu is 22.04.

• 64 bits Linux: krita-5.3.0-beta1-x86_64.AppImage

MacOS

• MacOS disk image: krita-5.3.0-beta1.dmg

Android

We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.

• 64 bits Intel CPU APK
• 64 bits Arm CPU APK
• 32 bits Arm CPU APK

Source code

You can build Krita 5.3 using the Krita 6.0.0.source archives. The difference is which version of Krita you build against.

md5sum

For all downloads, visit https://download.kde.org/unstable/krita/5.3.0-beta1/ and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

Krita 6.0. Download

NOTE: The main feature of the 6.0 release is that it uses Qt6. This means it is buggier than 5.3, having both the 5.3 bugs and Qt6 related bugs. If you have no need for the Krita 6.0 features, we recommend you use 5.3 for testing.

Windows

If you're using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.

• 64 bits Windows Installer: krita-6.0.0-setup.exe
• Portable 64 bits Windows: krita-6.0.0.zip
• Debug symbols. (Unpack in the Krita installation folder)

Linux

• 64 bits Linux: krita-6.0.0-x86_64.AppImage

MacOS

• MacOS disk image: krita-6.0.0-signed.dmg

Source code

• krita-6.0.0.tar.gz
• krita-6.0.0.tar.xz

md5sum

For all downloads, visit https://download.kde.org/unstable/krita/6.0.0-beta1/. and click on "Details" to get the hashes.

Key

The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key here. The signatures are here (filenames ending in .sig).

This year was my first year attending FOSDEM. I was encouraged to submit a talk and it got accepted. My talk was on Design Systems applied to Open Source projects.

In our case, I related the story and learnings from using a design system for the Plasma desktop. I outlined things that are pending or missing in this process.

I did my best to convince the audience to switch to Plasma and it seems a few of them changed their mind by the end of the talk.

This talk is a variation on my previous talk at Akademy 2025. Without further delay, here is the video recording of my talk. Note that the audio is not the best.

A recent toot of mine got the response “friends don’t let friends use GPG” which, I suppose, is true enough. It certainly isn’t the attestation-friendly thing to use, and the opsec failures that are so easy with GPG-encrypted mail make it a hazard there. But for some things it’s all we’ve got, and I do like to sign Calamares releases and incidental FreeBSD things. And I am nominally the maintainer of the security/gnupg port on FreeBSD. So gpg.fail notwithstanding, here’s notes on my 2026 GPG key update.

Previously in 2024 and 2025 I wrote down basically the same things:

• Things expire in about 13 months and I’ll have to remember then again,
• You can find my pubkey published on my personal and business sites,
• FreeBSD signature information is used rarely, but is available in the FreeBSD developers OpenPGP keys list,
• Codeberg will have signed commits in the Calamares repository with these keys.

sec   rsa4096/0x7FEA3DA6169C77D6 2016-06-11 [SC] [expires: 2027-02-03]
      Key fingerprint = 00AC D15E 25A7 9FEE 028B  0EE5 7FEA 3DA6 169C 77D6
uid                   [ultimate] Adriaan de Groot <groot@kde.org>
uid                   [ultimate] Adriaan de Groot <adriaan@bionicmutton.org>
uid                   [ultimate] Adriaan de Groot <adridg@freebsd.org>
uid                   [ultimate] Adriaan de Groot <adriaan@commonscaretakers.com>
ssb   ed25519/0x55734316C0AE465B 2025-03-04 [S] [expires: 2026-08-26]
ssb   cv25519/0x064A54E8D698F287 2025-03-04 [E] [expires: 2026-08-26]
ssb   ed25519/0x14B6CC381BC256D6 2026-02-03 [S] [expires: 2027-02-28]
ssb   cv25519/0xD716006BBA771051 2026-02-03 [E] [expires: 2027-02-28]

Hi all! I'm CJ, and I'm participating in Season of KDE 2026 by automating portions of the data collection for the KDE promo team. This post is an update on the work I've done in the first week of SoK.

My mentor gave me a light task to help me get set up and familiarize myself with the tools I'll be using for the rest of the project. The task was to automate the population of a spreadsheet that tracks follower and post counts for X (formerly known as Twitter), Mastodon, BlueSky, and Threads.

The spreadsheet takes the follower and post counts of some of KDE's social media platforms and makes calculations based off that data. Important things to note:

• data from the sites is entered manually
• there are a lot of styles and formulas in the sheet

Fetching Account Data

Grabbing data was mostly no trouble. Mastodon and BlueSky were especially easy to work with. They have a public and well documented API that lets people collect all kinds of data in human-readable formats. One particular endpoint from both sources output account information, including follower and post counts, for a given account in neat JSON files (BlueSky, Mastodon). All it took were GET requests to these endpoints and it was smooth sailing.

X and Threads proved a bit more finnicky. Both of their APIs limit access to much of their functionality usually meaning webscraping methods are the most accessible for grabbing public account data. Threads shows users' follower counts out directly on an account's landing page, so processing a GET request to the URL of KDE's Threads account made it easy to grab. The problem is that there seems to be no direct way to grab the post count either through their API or with webscraping methods. For now, we've chosen to leave that be and circle back when I explore Threads more in the future. X presents a similar problem but there is an open-source frontend alternative named Nitter, instances of which lay all the stats information out in the open. The reliability of this method depends on public Nitter instances being available so it may be worth coming back around to this in a later part of the project, but for now it's a viable solution for getting follower and post counts.

Inputting the Data Into the Spreadsheet

With the data all fetched, all that was left is to add that data to the ODF spreadsheet. I had this down as the easy part of the task but in the end it wasn't so simple. The two major Python packages I found that can interpret and write ODF files: Pandas and pyexcel. Both of these have no problem reading data from the files, but when it comes to saving they don't preserve some elements of the spreadsheet. In the end we went the simple route which is to save the data to a separate ODF file using one of the Python-ODF interfaces and import that into the data sheet. This took a little finagling with formulas to get things working without popping errors into cells the sheet, but in the end we have an output ODF spreadsheet file containing the required data and the original spreadsheet with all the calculations pulling that data into its formulas, removing any requirement of a human interfacing with this portion of data collection.

Learned Lessons

I feel like this week's task was a great first step into data collection automation. It was challenging without being too difficult to make progress on and forced me to explore different avenues for gathering data. On the confidence side, getting a (mostly) successful task out the gate helped me feel more comfortable with the tools and processes that will likely appear throughout the entirety of my SoK experience. Things will scale up from here on out though so I'm also keeping myself in check.

From what I understand some of the most difficult parts of automated data collection come through having to interface with Javascript and not getting banned, both of which I've yet to come face-to-face with in any substantial capacity so far. Along with that I've face unexpected problems, such as the issue with modifying ODF files and that some websites don't play as well with certain browsers, which I don't have an easy way to test for yet. With these in mind I'm trying to tread lightly and be diligent with research and good practice as I continue on.

Continuing previous efforts to update the “secure passwords” story of the Plasma desktop, I’ve done some integration work between Plasma and oo7.

Oo7 is a relatively recent SecretService provider written in Rust; it’s very nice, lightweight and cross-desktop. Very interesting for us supporting it as a first class citizen.

We want in the end to replace completely the old KWallet system with something based on SecretService, have all our applications migrated transparently with user data as well, if possible with a cross-desktop backend implementation.

We also want it to be as transparent as possible for the end user, not having any complicated first time setup, or dialogs that ask for a manual unlock when not needed. For the user, the whole system should be just invisible, except when looking up their passwords or when client applications add passwords to it themselves.

As a first thing several months ago we did a transparent translation layer for the KWallet DBus interface, so now the “KWallet” service became just a translation layer between the kwallet api and the secretservice one.

The old kwalletd service instead became “ksecretd” now providing only the SecretService interface, and that’s what we use by default now. however, it can be configured to use a different provider, so it can already be used with gnome-keyring or KeepassXC if the user wishes. In that case the user data will be migrated the first time.

Also I’ve written a new application called KeepSecret. It is centered around SecretService, with a much more modern UI compared to KWalletManager and works also much better on mobile, so we can have also a modern password manager on Plasma Mobile.

The last thing that we did so far is integration with a new SecretService provider on the block: oo7.

If oo7 is Just another SecretSerive provider, Won’t it “just work” in Plasma? Not quite, but that’s actually a good thing. Oo7 wants to properly integrate with the environment it runs in, so we need to build that integration.

When you use KWallet, KeepassXC, or gnome-keyring directly, they create their own password dialogs using their own toolkits and styles, therefore potentially looking a bit alien when run in a different environment than the one it it was designed for.

This is not ideal for evaluating options for a possible future replacement of KWallet (which piece by piece we are working towards), as we want the UI part completely integrated with the Plasma desktop.

Instead, oo7 is built on the assumption that the environment it runs on will provide its own dialogs, a bit like the portal system for services like screen sharing and file picking.
This requires active integration both on the Plasma part and the oo7 part, but on the other hand it will look native on Plasma, Gnome, and any other platform that implements the integration hooks. And that’s with the added benefit of sharing the password storage if someone every now and then goes desktop environment hopping.

On the Plasma side we decided to employ a very small daemon which is launched only on demand with dbus activation. It will create the needed system dialogs, pass the user input back to oo7 and then quit when not needed anymore, so it won’t constantly use up system resources.

This is already available in Plasma 6.6: the code for it is here. It’s designed first for oo7, but it can be used by any daemon which wishes to provide native password dialogs, so we might start to use it also from other components in the future, either other SecretService providers or completely different things which have similar needs like Polkit.

On the oo7 part, Harald implemented the integration with its dbus interface, so with oo7 from main branch (or its next release) it can be used in place of KWallet (with all old applications still using the KWallet API using its backend as well), with all data migrated to it, and it will show native UI for its password dialogs… all the pieces of the puzzle slowly falling together

Needless to say this is still at an experimental stage, but it’s an important milestone in getting more independent from the aging KWallet infrastructure.