The second and third betas for Krita 5.3.0/6.0.0 have been released, with the final release drawing near. There was also a hotfix stable release, 5.2.16, to fix a regression causing problems with HEIF files.
Read on for a look at development news and the Krita-Artists forum's featured artwork from last month.
This release contains exactly two regression fixes: some HEIF files not loading properly (bug), and the Move Tool movement shortcuts not working until clicking the canvas (bug).
If you're encountering either issue, update to 5.2.16.
The Krita Manual has been updated with all the new features in 5.3.0, thanks to the efforts of manual writer Wolthera and others.
Having trouble figuring something out? The friendly documentation is there to guide you in multiple languages, thanks to the ongoing work of all the translators!
The second beta and third beta for 5.3.0/6.0.0 were released, with many bug-fixes and a look at the new splash screen artwork by Tyson Tan.
Thanks to everyone who tested! The beta period is at an end with the final release right around the corner, but you can keep testing the latest nightly builds (found at the bottom of this post), and keep reporting bugs!
Zoom In/Out to Cursor is the default canvas input zoom again, and Zoom In/Out to Center is the alternatively configurable action. (bug; change by Carsten)
Some Krita 6 bugs were caused using an outdated version of Qt6. As updating Qt would cause too many issues before the final release, Dmitry backported the fixes to our version.
On Windows, Krita won't crash when news is enabled (bug; change) and menus won't instantly close when using a stylus with WinTab (bug 1, bug 2; change).
On Linux with Wayland, issues with incorrect stylus cursor position (bug 1, bug 2; change 1, change 2), wrong cursor shape (change), and shortcut keys being auto-repeated (bug; change) are fixed.
The Help menu's Report Bug item is back, so don't be shy to report bugs! (bug; change by Luna)
File Layers now allow Inherit Alpha and Layer Styles (change), .kra files used as File Layers now use their color profiles (bug; change), and renaming File, Filter, and Generator Layers is now undoable (bug; change), all thanks to Dmitry.
Agata fixed some regressions. Tools that auto-scroll when dragged to the edge of the canvas, such as the Selection tools, no longer scroll too much when zoomed in (bug change); Liquify Transform Masks no longer appear different than before (bug; change), plus the new Comics Panel Editing Tool no longer affects text (rather than turning characters into blocks) (bug; change)
On Android, a saving issue where the file is claimed to be unwritable was fixed by Carsten (change).
On Linux with X11/XWayland, there have been reports of Krita 6 running at a low framerate. The fix for this is to switch the OpenGL interface from GLX to EGL. This switch needs testing, so please read the EGL backend testing thread on how to do that and leave some feedback on whether it works or not.
Crashes were fixed when making a new vector layer after switching to a session (bug; change by Wolthera), converting the only layer of a group into a selection mask (bug; change by Dmitry), or on startup after removing a bundle containing tags. (change by Carsten)
More issues loading and saving HEIF images were fixed (bug; change 1, change 2 by Dmitry).
The Selection Actions Bar was fixed by Luna and Carsten to work with stylus or touch again, and have the right colors. (change 1, change 2; change 3)
More fixes to the Comic Panel Editing Tool by Agata (change): Only cut shapes the cut goes all the way through. Remove shapes that are small enough to be inside the cut gap. Work properly when using Shift for a straight line and putting the cursor on the end of the line. Don't add to the undo stack when nothing happened. The buttons and options have explanatory tooltips now (CCbug; change 1, change 2).
Krita 6 no longer crashes when loading window layouts. (bug; change by Gregg Jansen van Vuren)
On Linux with Wayland, pasting images with multiple sources in the clipboard no longer crashes. (bug; change by Luna)
Krita 6 on Windows no longer crashes when trying to open the background color selector. (bug; change by Dmitry)
A regression in beta 3 that broke translations on Android and Krita 6 has been fixed by Carsten and Freya (bug; change 1, change 2). Missing translations in Krita 6 were fixed by Dmitry and Ivan (change 1, change 2). Translations for some standard menu items such as 'New File' or 'About Krita' were also fixed for all versions. (bug; change by Dmitry)
The G'MIC plugin has been updated by Ivan to version 3.7.2 (change) and a crash when using the 'Layers Blend [Seamless]' filter was also fixed by Carsten (bug, change).
The usual plethora of text fixes by Wolthera:
In the Text Properties Docker, Line Height property is now visible by default (change) and the dropdowns are touch-scrollable (change by Carsten). The Style Presets preview now shows properly in paragraph mode (bug; change).
The Text Tool won't modify hidden or locked layers (bug; change). Rendering issues when undoing/redoing text modifications have been fixed (bug; change 1, change 2).
Text-on-path now works properly with RTL and end-anchors (change). Gradients are properly positioned on text-in-shape (change), and flow-text-in-shape only happens for filled shapes (change). Text-on-path can't also be inside a shape (bug; change).
Instead of crashing when loading a font on startup fails, a fallback font is loaded (bug; change). Try harder to load some fonts (CCbug; change 1, change 2).
If that wasn't enough bugfixes for you, there's even more listed in the "Additional Changes" section near the bottom of this post.
The next major release is almost here! But the work to improve Krita never ends, so the development team got together to decide their next priorities.
Read the 2026 Krita Roadmap post to find out what problems the team wants to address after 5.3/6.0.
The winner of the "Alien World Building" challenge is…
For March's theme, last month's winner has chosen "An unforgettable scene – 5 seconds before". Maybe you've got an artwork just waiting to happen?
This month's featured forum artwork, as voted in the Best of Krita-Artists - January/February 2026:
Participate in next month's nominations and voting to voice your opinion on the Best of Krita-Artists - February/March 2026.
Krita is free to use and modify, but it can only exist with the contributions of the community. A small sponsored team alongside volunteer programmers, artists, writers, testers, translators, and more from across the world keep development going.
If this software has value to you, consider donating to the Krita Development Fund. Or Get Involved and put your skills to use making Krita and its community better!
These pre-release versions of Krita are built every day.
Note that there are currently no Qt6 builds for Android.
Test out the upcoming Stable release in Krita Plus (5.3.0/6.0.0-prealpha): Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5
Or test out the latest Experimental features in Krita Next (5.4.0/6.1.0-prealpha). Feedback and bug reports are appreciated!: Linux Qt6 Qt5 — Windows Qt6 Qt5 — macOS Qt6 Qt5 — Android arm64 Qt5 – Android arm32 Qt5 – Android x86_64 Qt5
A while back I was writing a program that could instantiate an arbitrary number of windows containing controls synchronized across them. How a control would be synchronized would depend on a condition that determined which window instances would be linked to other instances. There are a few ways this could be implemented. In this entry I'll share my approach, in which I used a singleton C++ class serving as a message broker to bind properties across window instances.
Properties bound across multiple instances of a window
The software I wrote this for is a small app that allows you to have many windows open, all synchronized to display a single color on a per-monitor basis. The idea behind this is for users to adjust the light that comes off their monitors and use it to illuminate their faces when recording a video or taking pictures. By having individual windows be synchronized, users can continue to interact with the computer through their displays (rather inconveniently), while simultaneously using them to illuminate themselves.
This is, by no means, a replacement for a proper recording setup. Some of you will know that a light source placed in front of the subject can serve as either a nice "fill light" or a "scary spotlight", depending on the height and size of the source. Therefore, this should be complemented with other sources of light; ideally ambient light and a top light, to achieve a nice look. If the app seems useful to you, there's a link to it at the end of this article. That's enough gaffer speak for today. Let's talk about the code.
When writing code, one of my main concerns is always long-term maintainability. For that reason, I prefer to connect different parts of code in explicit, and easy to follow ways. One of such ways is passing values through a hierarchy of components; that is generally easy to track and produces well performing code. However, that approach can become unviable when connecting dynamically instantiated items to other dynamically instantiated items. A better solution in this instance is to use signals and slots to interconnect the items via a message broker class, done in C++. Each item would have a model or backend class in C++ and those classes would have the message broker in common. Lastly, the properties would be exposed to QML through Q_PROPERTY and updated via your control's signal handlers.
The message broker needs to be a singleton. That way there's only one instance of the broker in memory and all instantiated objects interface with the same broker. Our message broker only needs to provide the signals that will be used for routing properties. The actual connections that the routing involves are to be done from the outside. As such, a broker class would look like this:
@yowhatsup:matrix.org
// internalmessagebroker.hpp
// Singleton broker class contains signals that serve as pipes
// for different parts of a program to communicate with each other.
#pragma once
#include <QObject>
class InternalMessageBroker : public QObject
{
Q_OBJECT
// Hide regular constructor
private:
InternalMessageBroker() = default;
public:
// Disable copy constructor
InternalMessageBroker(const InternalMessageBroker& obj) = delete;
InternalMessageBroker& operator=(InternalMessageBroker const&) = delete;
static std::shared_ptr<InternalMessageBroker> instance()
{
static std::shared_ptr<InternalMessageBroker> sharedPtr{new InternalMessageBroker};
return sharedPtr;
}
// This is where all the signals would go
signals:
void broadcastAPropertyChange(int value, bool broadcast);
};Then we have the class or classes that would connect the properties together. On my Display Panels app, all controls and visual features come from QML, meaning I only have to concern myself with interconnecting the properties. To that end, I've created a class based on QObject and instantiated it within the delegate of a QML Instantiator. This class is only for managing property data, so I refer to it as a model class, called PropertiesModel:
// Main.qml
// Here are 3 windows, each with a PropertiesModel,
// that allows them all to share a binding to aProperty
// across all window instantiatons.
import QtQuick
import QtQuick.Window
import QtQuick.Layouts
import QtQuick.Controls
import com.kdab.example
Item {
Instantiator {
model: 3
delegate: Window {
PropertiesModel {
id: propertiesModel
aProperty: 1
}
ColumnLayout {
anchors.fill: parent
Text {
text: propertiesModel.aProperty
}
Slider {
id: hueSlider
value: propertiesModel.aProperty
Layout.fillWidth: true
onMoved: {
propertiesModel.aProperty = value;
}
}
}
}
}
}Each property of our class is to be declared using a Q_PROPERTY macro with a getter, a setter, and a notifier. The getter and the notifier have nothing out of the ordinary...
// An ordinary getter
int PropertiesModel::aProperty()
{
return m_aProperty;
}// An ordinary notifier, form propertiesmodel.h
signals:
void aPropertyChanged();However, the setter must be able to distinguish between when its call is the product of a user interaction and when it comes from the message broker. We accomplish this by having the setter accept a boolean argument (broadcast) that will be used to determine whether the value being set should be sent through the message broker or notified back to QML for the UI to be updated. When a setter is first called, the value being set should be broadcasted and only on its way back should the UI be updated.
There are a few ways we could make sure that the value is always broadcasted first. We could set broadcast to true by default, or have two setter functions: a private one taking in both the value and broadcast arguments and a public one that only takes-in the value and calls the private function with broadcast set to true. Another option is to have broadcast be an enum with only two possible values. That would produce more readable code, however, I didn't worry about that in my code because broadcast is only to be used on calls to the private setter.
Upon the private setter being called by the public setter, it will emit the broker's broadcast signal and that signal will in turn call the calling private setter for a second time (as well as the private setters of all other instances of PropertiesModel; those being called for the first time). When the private setter calls the broker that calls back to the private setter, it also passes broadcast set to false. All other instances will then evaluate the value of broadcast to be false determining that the UIs should be updated and preventing an infinite loop.
// Private setter implementation for a property that's being broadcasted
void PropertiesModel::setAProperty(const int value, const bool broadcast)
{
if (broadcast)
emit m_broker.get()->broadcastAPropertyChange(value, false);
else if (m_currentScreen == screenName) {
m_aProperty = value;
emit screenSaturationChanged();
}
}
// Publicly exposed setter prevents the broadcast argument from being
// specified by other callers
void PropertiesModel::setAProperty(const int value)
{
// Always broadcast properties not being set by the message broker
setAProperty(value, true);
}To complete this loop as described, we need to connect the signal from the broker to the private setter of the PropertiesModel class whenever a new copy is instantiated. The best place to accomplish that is from the class' constructor, like so:
// The constructor is used to connect signals from the broker to setter properties
PropertiesModel::PropertiesModel(QObject* parent)
: QObject { parent }
{
m_mb = InternalMessageBroker::instance();
// Connections take place after the class has been instantiated
// and its QML properties parsed.
QTimer::singleShot(0, this, [this] () {
connect(m_mb.get(), &InternalMessageBroker::aPropertyChange,
this, &ScreenModel::setAProperty);
});
}If you've been reading the blocks of code that accompany this article, you may be wondering "Why is there a singleShot QTimer there?" When the PropertiesModel class is instantiated via QML, any connected properties that have values assigned from QML code will trigger the Q_PROPERTY's setter function. This will happen once per instantiation. If the broker were connected, it would broadcast the value set to all currently instantiated instances every single time that a new instance is added. To prevent that, we must not make the connection to the broker until after a class has been fully initialized. A single shot timer can be used to accomplish that; setting its delay to 0 will ensure that it is run immediately after all properties have been evaluated.
In the end, this is what the PropertyModel header would look like:
// propertiesmodel.h
#pragma once
#include "internalmessagebroker.hpp"
#include <QQmlEngine>
class PropertiesModel : public QObject {
Q_OBJECT
QML_ELEMENT
Q_PROPERTY(int aProperty READ aProperty WRITE setAProperty NOTIFY aPropertyChanged FINAL)
public:
explicit PropertiesModel(QObject* parent = nullptr);
int aProperty();
void setAProperty(const int value);
signals:
void aPropertyChanged();
private:
void setAProperty(const int value, const bool broadcast);
std::shared_ptr<InternalMessageBroker> m_mb;
int m_aProperty;
};If a condition must be met for the propagated value to result in an update, then, in addition to value and broadcast, you should also broadcast any other values that are required to for such condition to be met. Pass those as arguments to the setter's and the broker's signal. Condition validation would then take place within the base case of the private setter. Here's a commented snippet of what that looks like on the Display to Light Panels app that this article was based on:
// In the original code what here I named broadcast used to be named spread.
void ScreenModel::setScreenHue(const int hue, const bool spread=true, const QString &screenName="s")
{
if (spread)
emit m_mb.get()->spreadHueChange(hue, false, m_currentScreen);
// The incoming value is only accepted if screenName matches the screen
// that the window is at and discarded otherwise.
else if (m_currentScreen == screenName) {
m_screens[m_currentScreen].hue = hue;
emit screenHueChanged();
}
}
Properties bound across instances of a window
For a real world application, you can read the code for Display to Light Panels, the app that inspired this article, at: https://github.com/Cuperino/Display-to-Light-Panels
If you need help solving architecture problems, such as this one, reach out to us and we will gladly find ways in which we can help.
The post Bind QML Values across an Arbitrary Number of Elements appeared first on KDAB.
I had an amazing time at the Season of KDE 2026. All the guidance from my mentors, Benson Muite and Srisharan VS, really helped me work on Mankala and also helped me learn new skills.
So, lets summarize things a bit, what I was able to achieve during the span of these two months at KDE.
I started learning about Lokalize, KDE’s own translation software. I had successfully made translations for Mankala Engine and MankalaNextGen in Tamil and Hindi using Lokalize.
The journey doesn’t end here. Season of KDE has been a much-needed experience to improve my commitment towards projects and open-source. I plan to work with Mankala Engine and the KDE Community much more and make many other contributions.
Thanks to my mentors, my fellow contributors, and to the entire community for helping me so far. 🚀
KDE Gears 26.04 hit beta phase just a few days ago, so it is time to give an update on the new features in KJournald.
For 26.04, the main release goal was to have a natural integration of systemd user services and system services in the log view workflow. This means:
Revisiting the overall UI with this feature in mind, we need few more changes to really make it fly:
If you interested in the features, try out the KDE Gears beta release or just install the latest nightly build of org.kde.kjournaldbrowser from the KDE Flatpak nightly CI.
There is a lot of talk about digital sovereignty. Being able to act as a state or as a company is obviously important. But there are real dependencies, and given the current geopolitical dynamics, there are real risks. Unfortunately, there are no easy answers. Digital sovereignty matters, but so do stability, efficiency, and innovation. Fortunately, there are options and some good examples of how to deal with it. I collected some material in an awesome list on digital sovereignty.
While it is complex at the state level, it is merely complicated at the personal level. Reaching something like personal digital sovereignty is possible. If you are informed about the technical landscape, you probably already have a good intuition about it. You feel the pain of having to stop using a service because the provider decided to discontinue it without you having a say. You can decide whether it feels right to upload your personal diary to a server in a jurisdiction you do not control.
There is a clear path to personal digital sovereignty. The goal is nicely expressed in KDE's mission: "A world in which everyone has control over their digital life and enjoys freedom and privacy." The path is provided by Free Software. The freedoms to use, study, share, and improve give you exactly what you need to be in control.
For software you run yourself, this works well. Running Free Software on your personal computer gives you control. It feels good. It becomes more complicated when you use services you do not and cannot run yourself. The software freedoms do not transfer easily. There are a lot of services, which are mostly based on Free Software, but only the service providers enjoy the freedoms, not their users. I have written about this before when working on my Fair Web Services project.
A good testament to personal digital sovereignty is the Blue Angel for software. Its focus on resource and energy efficiency is one side of responsible software use. Maybe even more important is its emphasis on user autonomy: being able to use software without ads being forced on you, being able to choose what to install, and having transparency about what you run. These are the ingredients of personal digital sovereignty.
Freedom is one side, but convenience is another. Sometimes it is easier to just use something a vendor has invested heavily in providing, even if you pay with your data and some independence. It is also a question of where you spend your time: do you build something for yourself, or do you use something that already exists? And sometimes it is about the limits what you can do yourself. Powerful tools can give you leverage so you can focus on your actual mission.
So it is also about compromise. One very important aspect for me is that I am still able to choose. That is the core of personal digital sovereignty. Sovereignty does not mean doing everything yourself. It means preserving the ability to leave, even if you choose not to.
Federated services make it easy to migrate. For git, for example, it does not matter so much where the server is or who runs it, because switching is as simple as changing the remote. For a proprietary note-taking service, this looks different. You may need special exports, format conversions, and you might lose functionality because it is not based on open standards. Choose your dependencies wisely.
It is important to remember that dependencies are not bad per se. We know this from Free Software. We know what it feels like to stand on the shoulders of giants. We rely on the collective strength of a global community. It is not about rejecting all dependencies or doing everything on your own. It is about creating alternatives and shaping an ecosystem based on openness, so that we can choose and act on our own terms.
I am quite happy with my personal stack, which gives me the control I need. My 12-year-old desktop runs Linux and KDE. I pay to host my own email, Nextcloud, and git services. One project I particularly like is GitJournal, which gives me control over my note-taking across all my devices. This covers the core of my computing needs, with my family, my friends, and what I decide to keep private.
To stay connected to the wider world, there is no way around being present on large networks. GitHub and LinkedIn are the compromises that give me reach without requiring me to abandon all my principles. I would not publish my writing only on LinkedIn, though, because I want to own what I produce.
AI is a difficult question right now. It is easy to switch between services, and with rapid development it is changing quickly what the best choice is. And it can provide tremendous leverage. So it remains an evolving compromise. An ideal future would offer open models powerful enough to serve your needs and that you can run locally.
On a personal level, you can decide for yourself. There are limitations, and you will have to build on the environment available to you. But there are alternatives, and you can choose to build your personal digital sovereignty.
At the corporate and state level, it is more difficult. The systems are more intertwined, but the pain of dependencies you cannot control and the risks of others making decisions for you are just as real. Alternatives exist there as well, often the same ones available on a personal level. It can be worth taking bold decisions.
Digital sovereignty at the state level is about national security. At the personal level, it is about personal freedom. Free Software provides a powerful path to maintaining control over our digital lives.
I am not arguing for tools. I am arguing for agency.
toscalix
GSoC