Here’s an overview of recent work around Android platform support for KDE Frameworks
and KDE applications, most of which is a direct result of discussions and work
at Akademy and the
Matrix conference.
Notification permission fixes
Porting Itinerary and NeoChat to use
the KNotification permission API
identified two issues around permission checks and callbacks on permission changes that
resulted in the application seeing the wrong permission state. That’s fixed now.
Retirement of the Qt 5 CI
With the 24.08 KDE Gear release all our Android apps are based on Qt 6, including their
stable release branches. We have therefore started with retiring
the Android Qt 5 CI/CD infrastructure, which should save us both maintenance and computing
resources.
As Qt 5 is meanwhile lagging behind several Android SDK versions it’s no longer a viable
platform for producing APKs that work on up-to-date devices anymore anyway.
Android CI has meanwhile been removed from the KDE Frameworks 5 maintenance branches as well
as from a few other libraries that still used it. The removal of Gitlab CI templates, Craft
caches and container images will follow.
In particular this means the invent-registry.kde.org/sysadmin/ci-images/android-qt515 container image
is deprecated and will be removed eventually. Please get in touch if you are still using this externally.
Poppler’s CI was such a case for example.
QML file installation
The QML module macros in ECM used to install QML files to disk, besides bundling those via the Qt resource system as well.
While that is still needed on most platforms due to some specific code in Kirigami, it’s unnecessary on Android
where we rely solely on the bundled data.
This resulted in unnecessary content in the APKs, which has been fixed
and makes all our APKs a bit smaller now.
Translation lookup order
The probably most visible change is a fix
for a long standing bug in KI18n’s multi-language fallback lookup order,
which would result in applications showing a wild mix of languages under certain conditions.
This happened when the primary device language was set to English but the country to anything
but the US or the UK and one or more secondary languages were also selected. While not strictly
limited to Android, there’s two factors that made it particularly prone to happen there:
Newer Android versions allow language and country to be set fully independently, while on
many other systems only certain predefined combinations are available.
The language setting doesn’t just impact application translations but also text input, so
many more users have multiple languages configured.
KI18n first looks for a translation for the specific language/country pair and then
just the language, before falling back to the next configured language/country pair. If no translation
is found it’ll eventually use the English/US source text.
Conceptually this is not wrong, but the implementation missed the fact that there is no
“country-less” English translation but only the English/US source text. A configuration of
English/Canada and French/Canada therefore previously resulted in a French translation rather
than an English one, as it does now.
This has been backported and should be available in all our APKs with 24.08.2 latest.
Runtime language change
Thanks to input from Fabian during Akademy there’s also significant progress on
having applications react to system language changes at runtime.
This basically consists of three parts:
Propagate the native Android system configuration change to Qt, done in
Qt CR 596175.
Reset cached values inside KI18n on system language changes, done in
KI18n MR 124.
Trigger QML binding re-evaluation for i18n() calls on language changes,
implemented in KI18n MR 127.
With those three changes applied and a few lines adjusted in the application code to
make use of this large parts of the UI already follow system language changes automatically.
It’s far not perfect yet, as there’s more things that need to update in this case than
just translated strings. Date/time formatting for example, as discussed in QTBUG-129727.
But overall this is already much better than what I had expected and assumed to be feasible
with realistic effort.
Dark mode support
As reported previously
we have working support for dark mode since 24.08.1, thanks to Julius’ work on icon recoloring.
So far this required minimal changes to applications to enable it though. That has
also been fixed, dark mode
support is now automatically enabled for all applications using the Breeze style.
Outlook
There’s still more to do regarding Android platform integration.
I’d say the two probably most pressing issues are the following:
On some devices the font size is unusably small, caused by the display scale factor being wrong.
Based on some investigation during Akademy the current working theory is that this is a race condition
in Qt’s code reading that information. I have no device/setup that reproduces this problem unfortunately.
Selecting files in the platform file dialog that are located on a cloud storage such as Nextcloud
silently fails. That is, to the application selecting such a file looks as if the user had canceled the dialog. Here we know
exactly why this happens (it’s explicit code in Qt doing this, for valid reasons), the challenge is rather
to find a proper solution.
If you are interested in Android integration for KDE applications, feel free to join us in the
#kde-android Matrix channel!
And I’d say it’s a pretty good release! As with all large sets of changes, there are a couple of regressions we’re tracking, particularly around the areas of external monitor brightness and multi-screen performance. They are being actively investigated. Other than those, so far all the issues have been fairly minor, requiring people to jump through various hoops to experience them. We’re still working on fixing them, of course! I’ll be writing up another post soon on these issues, discussing how they snuck into the final release, and what we can learn from the experience.
But in the meantime, here’s the Plasma team’s work from this week:
Notable UI Improvements
Removed some unintentional extra padding around everything on System Settings’ Touchpad page (me: Nate Graham, Plasma 6.2.1. Link):
Notable Bug Fixes
Fixed a regression in Plasma that caused pop-ups of widgets on a Plasma panel to get positioned partially off screen, but only if their parent panel was very small and positioned against on the left or top screen edge (Niccolò Venerandi, Plasma 6.2.1. Link)
Fixed a regression in the new “control all screens’ brightness” feature that caused the brightness slider for external screens to get duplicated with certain screens (Jakob Petsovits, Plasma 6.2.1. Link)
Fixed two minor window focus regressions caused by an intentional change in KWin’s multi-monitor focus behavior (Vlad Zahorodnii, Plasma 6.2.1. Link 1 and link 2)
Fixed a porting regression that caused the virtual desktop switcher OSD to not appear when it should have (Vlad Zahorodnii, Plasma 6.2.1. Link)
Fixed a porting regression that caused the first entry in the clipboard to temporarily not be removable after editing it (Fushan Wen, Plasma 6.2.1. Link)
Fixed a porting regression that caused auto-mounted encrypted disks to mount normally as expected, but not show up correctly in Plasma’s Disks & Devices widget (Bohdan Onofriichuk, Plasma 6.2.1. Link)
Fixed three Plasma crashes affecting the System Tray and Disks & Devices widget under various circumstances (Fushan Wen, Plasma 6.2.1. Link 1, link 2, and link 3)
Fixed a case where Plasma could crash in brightness-related code (Jakob Petsovits, Plasma 6.2.1. Link)
Fixed a bug in our KPipeWire library (which lives in Plasma) that caused screen recordings in Spectacle using the default VP9 video codec to be cut off at the end on slower systems (Arjen Hiemstra, Plasma 6.2.1. Link)
Fixed a bug that caused configuration pages of System Monitor widgets to not be scrollable when needed (Arjen Hiemstra, Plasma 6.2.1. Link)
Fixed an unusual bug that caused the system to fail to log out within the first 50 seconds after logging in, but only when the splash screen was disabled (David Edmundson, Plasma 6.2.1. Link 1 and link 2)
System Settings’ Wallpapers page now has a visible title as expected (Méven Car, Plasma 6.2.1. Link)
The Baloo file indexer service no longer tries to pointlessly index the content of .obj 3D model files (Someone going by the pseudonym “Archaeopteryx Lithographica”, Frameworks 6.8. Link)
If you’re an enthusiastic user, don’t sweat them and upgrade anyway. It’s a fantastic release.
Otherwise, visit https://community.kde.org/Get_Involved to discover additional ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite! Or consider donating instead! That helps too.
Looks like we properly live by the “simple by default, powerful when needed” tagline. Now there are also challenges, this article gives a nice balanced view.
It’s Not Easy Being Green: On the Energy Efficiency of Programming Languages
Tags: tech, programming, performance, energy
Nice paper which debunks the choice of the language as an important factor for energy efficiency. The previous papers had a too simple model, this one puts forth a more complete causal model. There are many factors at play regarding energy efficiency, the programming language itself is not really one of them.
Excellent point, we made the web too complex for regular users. This is actually an issue in term of access and democracy for people to write content there.
Yes, the governance of Open Source projects can be tricky. This is part of the job though, and properly embraced we all go further. An example from the Wayland space.
Nice post, and indeed it’s not about Python if you read until the end. It shows that it’s important to be able to make informed choices and not just pick your tech stack based on knee-jerk reactions.
Put business logic in the application, not the database
Tags: tech, databases, design, performance
I’m not sure I’m sold on this one. Interesting food for thought but I’ll have to mull it over for a while I think. I’m concerned about the performance implications of querying like this.
Understanding and effectively mitigating code review anxiety
Tags: tech, codereview, psychology, cognition, anxiety, research
Still very early days on this topic, clearly more studies are required. Still this one is interesting and indicates are clear link between code review anxiety and code review avoidance. If you’re often procrastinating or rubber stamping code reviews, a workshop to reduce biases and showing you can manage your anxiety could improve things greatly.
The latest Nobel prizes indeed say something about the presence of computer scientists in other fields. Do we risk to delve too much on theoretical model? For sure using computers helps a lot, we have to be careful about not loosing empirical validation in the process.
KDE today announces the release of KDE Frameworks 6.7.0.
KDE Frameworks are 72 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.
This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.
We have just switched on the upgrade for KDE neon to rebase on Ubuntu 24.04 LTS.
We do this every two years and the 22.04 LTS base was getting increasingly crusty with old Pipewire causing problems and packages like Krita not compiling at all.
The Kubuntu Team is happy to announce that Kubuntu 24.10 has been released, featuring the new and beautiful KDE Plasma 6.1 simple by default, powerful when needed.
Codenamed “Oracular Oriole”, Kubuntu 24.10 continues our tradition of giving you Friendly Computing by integrating the latest and greatest open source technologies into a high-quality, easy-to-use Linux distribution.
Under the hood, there have been updates to many core packages, including a new 6.11 based kernel, KDE Frameworks 5.116 and 6.6.0, KDE Plasma 6.1 and many updated KDE gear applications.
Kubuntu 24.10 with Plasma 6.1
Kubuntu has seen many updates for other applications, both in our default install, and installable from the Ubuntu archive.
Applications for core day-to-day usage are included and updated, such as Firefox, and LibreOffice.
For a list of other application updates, and known bugs be sure to read our release notes.
Wayland as default Plasma session.
The Plasma wayland session is now the default option in sddm (display manager login screen). An X11 session can be selected instead if desired. The last used session type will be remembered, so you do not have to switch type on each login.
Note: For upgrades from 24.04, there may a delay of a few hours to days between the official release announcements and the Ubuntu Release Team enabling upgrades.
We’re very happy to announce the latest release of Qt for Python 6.8. With every new release, we try to bring great things with Qt's new features and new trending ideas. For your convenience, you can check out what's new in Qt for Python 6.8 and what’s improved, along with the entire change log.
Kirigami Addons is out. This releases contains mostly code cleanup and minor
improvements. There is netherless a few relevant changes. Thanks to everyone
who contributed some code.
New KAppTemplate’s template
A new KAppTemplate is available as a good starting point for application that
manage multimedia libraries. It is based on shared design of
Peruse,
Arianna and the WIP Calligra Launcher.
Hopefully it helps people who want to develop game launchers and other type of
specialized multimedia applications.
More templates are planned (e.g. for chat applications), so stay tunned!
FormCard
FormCard is the part of Kirigami Addons that received the most changes in this
release. First of all, FormCard now use more consistent spacing and padding,
which slighly less horizontal padding. Descriptions for radio and checkbox
delegates are also put underneath the delegate’s main text and checkbox, in an
effort to make FormCard a bit more compact.
Before
After
Additionally FormComboBoxDelegate now lets you display an inline status
similar to that is available in other FormCard’s delegates.
Finally FormCard.AboutKDE was renamed to FormCard.AboutKDEPage. This improve
the naming consistency with other page compoenents. A compatibility wrapper on
top of AboutKDEPage named AboutKDE is still available to not break any
existing applications.
Deprecations
The Banner component is now deprecated. Kirigami.InlineMessage now has a
position parameter which can be set to Header or Footer. Additionally
with KDE Frameworks 6.8 Kirigami.InlineMessage will look exactly the same as
Banner! So there is no more reasons for this component to exists
in Kirigami Addons.
Other
Kirigami Addons supports static builds with a recent enough version of extra-cmake-modules.
I've been fixing cursor problems on and off in the last few months. Here's a recap of what I've done, explanation of some cursor size problems you might encounter, and how new developments like Wayland cursor shape protocol and SVG cursors might improve the situation.
(I'm by no means an expert on cursors, X11 or Wayland, so please correct me if I'm wrong.)
Why don't we have cursors in the same size anymore?
My involvement with cursors started back in the end of 2023, when KDE Plasma 6.0 was about to be released. A major change in 6.0 was enabling Wayland by default. And if you enabled global scaling in Wayland, especially with a fractional scale like 2.5x, cursor sizes would be a mess across various apps (the upper row: Breeze cursors in Plasma 6.0 Beta 1, Wayland, 2.5x global scale, the lower row: Same cursors in Plasma 6.0):
So I dug into the code of my favorite terminal emulator, Kitty, which at the time drew the cursor in a slightly smaller size than it should be (similar to vscode in the above image). I gained some understanding of the problem, and eventually fixed it. Let me explain.
How to draw cursors in the same size in different apps?
In X11, there used to be a standard set of cursors, but nowadays most apps use the XCursor lib to load a (user-specified) cursor theme and draw the cursor themselves. So in order to have cursors in the same theme and size across apps, we need to make sure that:
Apps get the same cursor theme and size from the system.
Apps draw the cursor in the same way.
The transition to Wayland created difficulties in both points:
1. Get the same cursor theme and size from the system
It used to be simple in X11: we have Xcursor.size and Xcursor.theme in xrdb, also XCURSOR_SIZE and XCURSOR_THEME in environment variables. Setting them to the same value would make sure that all apps get the same cursor theme and size.
But Wayland apps don't use xrdb, and they interpret XCURSOR_SIZE differently: in X11, the size is in physical pixels, but in Wayland it's in logical pixels. E.g., if you have a cursor size 24 and global scale 2x, then in X11, XCURSOR_SIZE should be 48, but in Wayland it should be 24.
The Wayland way is necessary. Imagine you have two monitors with different DPI, e.g. they are both 24" but monitor A is 1920x1080, while monitor B is 3840x2160. You set scale=1 for A and scale=2 for B, so UI elements would be the same size on both monitors. Then you would also want the cursor to be of the same size on both monitors, which requires it to have 2x more physical pixels on B than on A, but it would be the same logical pixels.
So Plasma 6.0 no longer sets the two environment variables, because XCURSOR_SIZE can't be simultaneously correct for both X11 and Wayland apps. But without them and xrdb, Wayland apps no longer have a standard way to get the cursor theme and size. Instead, different frameworks / toolkits have their own ways. In Plasma, KDE / Qt apps get them from the Qt platform integration plugin provided by Plasma, GTK4 apps from ~/.config/gtk-4.0/settings.ini (also set by Plasma), Flatpak GTK apps from the GTK-specific configs in XDG Settings Portal.
The last one is particularly weird, as you need to install xdg-desktop-portal-gtk in order fix Flatpak apps in Plasma, which surprised many. It might seem like a hack, but it's not. Plasma officially recommends installing xdg-desktop-portal-gtk, and this was suggested by GNOME developers.
But what for 3rd-party Wayland apps besides GTK and Qt? The best hope is to read settings in either the GTK or the Qt way, piggy-backing the two major toolkits, assuming that the DE would at least take care of the two.
(IMHO either Wayland or the XDG Settings Portal should provide a standard way for apps to get the cursor theme and size.)
That was part of the problem in Kitty. It used to read settings from the GTK portal, but only under a GNOME session. I changed it to always try to read from the portal, even if under Plasma. But that's not the end of the story...
2. Draw the cursor in the same way
It's practically a non-issue in X11, as the user usually sets a size that the cursor theme provides, and the app just draws the cursor images as-is. But if you do set a cursor size not available in the theme (you can't do that in the cursor theme settings UI, but you can manually set XCURSOR_SIZE), you'll open a can of worms: various toolkits / apps deal with it differently:
Some just use the closest size available (Electron and Kitty at the time), so it can be a bit smaller.
Some use the XCursor default size 24, so it's a lot smaller.
Some scale the cursor to the desired size, and the scaling algorithm might be different, resulting in pixelated or blurry cursors; Also they might scale from either the default size or the closest size available, resulting in very blurry (GTK) or slightly blurry (Qt) cursors.
The situation becomes worse with Wayland, as the user now specifies the size in logical pixels, then apps need to multiply it by the global scale to get the size in physical pixels, and try to load a cursor in that size. (If the app load the cursor in the logical size, then either the app or the compositor needs to scale it, resulting in a blurry / pixelated cursor.) With fractional scaling, it's even more likely that the required physical size is not available in the theme (which typically has only 2~5 sizes), and you see the result in the picture above.
One way to fix it (and why I didn't do)
It can be fixed by moving the "when we can't load cursors in the size we need, load a different size and scale it" logic from apps / toolkits to the XCursor lib. When the app requests cursors in a size, instead of returning the closest size available, the lib could scale the image to the requested size. So apps would always get the cursor in the size they ask for, and their own different scaling algorithms won't get a chance to run.
Either the default behavior can be changed, or it can be hidden behind a new option. But I didn't do that, because I felt at the time that it would be difficult to either convince XCursor lib maintainers to make a (potentially breaking) change to the default behavior, or to go around convincing all apps / toolkits to use a new option.
My fix (or shall we say workaround)
Then it came to me that although I can't fix all these toolkits / apps, they seem to all work the same way if the required physical size is available in the theme - then they just draw the cursor as-is. So I added a lot of sizes to the Breeze theme. It only has size 24, 36 and 48 at the time, but I added physical sizes corresponding to a logical size 24 and all global scales that Plasma allows, from 0.5x to 3x, So it's 12, 18, 24 ... all the way to 72.
It was easy. The source code of the Breeze theme is SVG (so are most other themes). Then a build script renders it into images using Inkscape, and packages them to XCursor format. The script has a list of the sizes it renders in, so I added a lot more.
And it worked! If you choose Breeze and size 24, then (as in the bottom row in the picture above) various apps draw the cursor in the same size at any global scale available in Plasma.
But this method has its limitations:
We can't do that to 3rd-party themes, as we don't have their source SVG.
It only works if you choose the default size 24. If you choose a different size, e.g. 36, and a global scale 3x, then the physical size 36x3=108 is not available in the theme, and you see the mess again. But we can't add sizes infinitely, as explained in Vlad's blog, the XCursor format stores cursor images uncompressed, so the binary size grows very fast when adding larger sizes.
Both limitations can be lifted with SVG cursors. But before getting to that, let's talk about the "right" way to fix the cursor size problem:
The "right" fix: Wayland cursor shape protocol
The simple and reliable way to get consistent cursors across apps is to not let apps draw the cursor at all. Instead, they only specify the name of the cursor shape, and the compositor draws the cursor for them. This is how Wayland cursor shape protocol works. Apps no longer need to care about the cursor theme and size (well, they might still need the size, if they want to draw custom cursors in the same size as standard shapes), and since the compositor is the only program drawing the cursor, it's guaranteed to be consistent for all apps using the protocol.
(It's quite interesting that we seem to went a full circle back to the original server-defined cursor font way in X11.)
Support for this protocol leaves a lot to improve, though. Not all compositors support it. On the client side, both Qt and Electron have the support, but GTK doesn't.
There are merge requests for GTK and Mutter, but GNOME devs request some modifications in the Wayland protocol before merging them, and the request seems to be stuck for some months. I hope the recent Wayland "things" could move it out of this seemingly deadlock.
Anyway, with this protocol, only the compositor has to be modified to support a new way to draw cursors. This makes it much easier to change how cursors work. So we come to:
SVG cursors
Immediately after the fix in Breeze, I proposed this idea of shipping the source SVG files of the Breeze cursor theme to the end user, and re-generate the XCursor files whenever the user changes the cursor size or global scale. This way, the theme will always be able to provide the exact size requested by apps. (Similar to the "modify XCursor lib" idea, but in a different way.) It would remove the limitation 2 above (and also limitation 1 if 3rd-party themes ship their source SVGs too).
With SVG cursors support in KWin and Breeze, I plan to implement this idea. It would also allow the user to set arbitrary cursor size, instead of limited to a predefined list.
Problems you might still encounter today
Huge cursors in GTK4 apps
It's a new problem in GTK 4.16. If you use the Breeze cursor theme and a large global scale like 2x or 3x, you get huge cursors:
It has not limited to Plasma. Using Breeze in GNOME would result in the same problem. To explain it, let me first introduce the concept of "nominal size" and "image size" in XCursor.
Here is GNOME's default cursor theme, Adwaita:
"Nominal size" is the "cursor size" we are talking about above. It makes the list of sizes you choose from in the cursor theme settings UI. It's also the size you set in XCURSOR_SIZE. "Image size" is the actual size of the cursor image. "Hot spot" is the point in the image where the cursor is pointing at.
Things are a bit different in the Plasma default cursor theme, Breeze:
Unlike Adwaita, the image size is larger than the nominal size. That, combined with a global scale, triggers the bug in GTK4. Explanation of the bug.
XCursor allows the image size to be different from the nominal size. I don't know why it was designed this way, but my guess is so you can crop the empty part of the image. This both reduces file size, and reduces flicking when the cursor changes (with software cursors under X11). But the image size can also be larger than the nominal size, and Breeze (and a lot of other themes) uses this feature.
You can see in the above images that the "arrow" of nominal size 24 in Breeze is actually similar in size to the same nominal size in Adwaita. But the "badge" in Breeze is further apart, so it can't fit into a 24x24 image. That's why Breeze is built this way. In a sense, "nominal size" is similar to how "font size" works, where it resembles the "main part" of a character in the font, but some characters can have "extra parts" that go through the ceiling or floor.
This problem is already fixed in the main branch of GTK 4, but it's not backported to 4.16 yet, probably because the fix uses a Wayland feature that Mutter doesn't support yet. So at the moment, your only option is to use a different cursor theme whose "nominal size" and "image size" are equal.
Smaller cursors in GTK3 apps (most notably, Firefox)
The cursor code in GTK3 is different from GTK4, with its own limitations. You might find the cursor to be smaller than in other apps, and if you run the app in a terminal, you might see warnings like:
cursor image size (64x64) not an integer multiple of scale (3)
GTK3 doesn't support fractional scales in cursors. So if you have cursor size 24 and global scale 2.5x or 3x, it will use a scale 3x and try to load a cursor with a nominal size 24x3=72. And it requires the image size to be an integer multiple of the scale. So if your theme doesn't have a size 72, or it does but the image size is not multiple of 3, GTK3 fallbacks to a smaller unscaled cursor.
End words
OK, this is a long post. Hope I can bring you more cursor goodies in Plasma 6.3 and beyond.
@vkrause:kde.org
ngraham
