Akademy-es 2026 is happening October 23 to 25 in Camping Arco Iris (Villaviciosa de Odón, Madrid)
For the 20th anniversary of the first Akademy-es, the organizers have chosen a campsite to do a slightly different event focusing on the community side of KDE.
There will still be of course talks, so remember you can submit one until this September 13th!
See you there!
Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.
AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.
Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).
Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.
The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.
But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.
To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.
For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.
Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).
For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.
So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:
| Icon size | Icons | PNG total | JXL total | Pool saved | PNG avg | JXL avg | Median saved | Mean saved | Worst | Best | Larger as JXL |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 48×48 | 1544 | 3.7 MiB | 3.0 MiB | 17.8% | 2.4 KiB | 2.0 KiB | 17.9% | 16.7% | -118.7% | 60.0% | 206 |
| 64×64 | 2018 | 7.0 MiB | 5.8 MiB | 17.8% | 3.6 KiB | 2.9 KiB | 18.0% | 15.8% | -112.7% | 70.0% | 279 |
| 128×128 | 1411 | 11.2 MiB | 8.7 MiB | 22.0% | 8.1 KiB | 6.3 KiB | 20.1% | 17.5% | -89.7% | 61.0% | 209 |
| TOTAL | 4973 | 21.9 MiB | 17.5 MiB | 19.9% | 4.5 KiB | 3.6 KiB | 18.6% | 16.6% | -118.7% | 70.0% | 694 |
PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.
As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.
As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.
In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).
The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:
My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.
Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).
The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:
For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.
Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.
If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).
JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).
This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.
It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.
Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).
The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.
AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.
As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).
The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).
With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).
Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.
Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.
With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.
For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.
As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.
Besides maintenance and debugging work, this year, my work on Kdenlive was mostly dedicated to refactoring the Kdenlive keyframes system to make it more powerful. This is part of a NGI Zero Commons grant via NLnet, see my last status report from february for some more context.
Previously, keyframes were set globally for an effect, touching all its parameters. With the updated logic, you can now decide to add keyframes only to a specific parameter, and parameters can have independant keyframes. This work will soon be made available for testing, and will be part of the next 26.12.0 Kdenlive release.
This new widget allows to move keyframes for several effects in one step, and also supports keyframe scaling, meaning that you can easily stretch a group of keyframes.
Basic keyframe features remain in the effect stack, like add/remove keyframe and seek to previous/next keyframe, but all other keyframe-related features have otherwise been removed from the effect stack into a dedicated Keyframes panel. The parameter values now have a colored background to indicate if you are currently on a keyframe or not.
One drawback is that it uses more space, but we plan to futher refine the interface in the next months before the final release.
Beyond the obvious possibility to add per-parameter keyframes, and manage keyframes from several effects in one place, a few other features were included in the rewrite:
You can now grab the selected keyframes with the usual shortcut, then move them frame by frame using arrow keys.
Zooming and scrolling can be used with the standard mouse wheel events, and it is now possible to scale selected keyframes by selecting them and dragging with the Ctrl modifier.
The Keyframes interface also allows to filter parameters by name to only show matching parameters, useful if you have lots of effects on a clip. All this work will also make it much easier to add new keyframe features in the future.
"Adding new features is nice, but what about performance?" you may ask. Well, good news: this work also involved some cleanup and performance improvements. People working with lots of keyframes (for example with object tracking) will really enjoy the changes.
For example if you have a clip with more than 1000 keyframes, you will enjoy:
And even if you don't use that many keyframes, the general workflow should be a lot smoother.
Part of the Kdenlive team will be in Graz for KDE's Akademy, celebrating 30 years of KDE. Be there to meet us!
Our small team has been working for years to build an intuitive open source video editor that does not track you, does not use your data, and respects your privacy. However, to ensure a proper development requires resources, so please consider a donation if you enjoy using Kdenlive - even small amounts can make a big difference.
Over 180 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.
Today they all get new bugfix source releases with updated translations, including:
Distro and app store packagers should update their application packages.
Here are the new modules available in the Plasma 6.8 beta:
Some important features and changes included in 6.8 beta are highlighted on KDE community wiki page.
This releases marks the second half of the Union theming system’s public tech preview!
New in Plasma 6.8: Union now themes QtWidgets applications, such as Dolphin and Kate. Bear in mind this support is preliminary and you will encounter bugs. When you do, please report them here!
To test Union:
TSDgeos
union package is installed (name may differ depending on your distro)This will apply Union styling to both QtQuick and QtWidgets apps.
The intention is for these apps to look as similar as possible when styled with Union to how they look with Breeze — though any minor visual improvements should be considered intentional!
If you find any issues, make sure they’re Union-specific by running the app with the Breeze style to compare the two. If the issue is Union-specific, report it here!
Wednesday, 9 September 2026
KDE today announces the release of KDE Frameworks 6.30.0.
This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.
I tagged v0.0.11 last night. Or this morning. I’ve stopped keeping track of which side of midnight things happen on.
Most of what’s in this tag I already went on about on Monday, in the weekly update: the harp swapping, the Guitar Pro files, the pitch detectors that turn out not to hear chords. Go read that one if you want the long version, and it is a long version, I checked. This is only about the four things that landed after I wrote it.
Four things. Well. Three things, because one of them was me deleting a line out of a TODO file, and I’m not going to make you read a paragraph about that.
So there was this line in my TODO list, and it said my chromatic harmonica was modelled as reaching less of its range than a diatonic, which is backwards. Chromatics are the ones that get all the notes. That’s the deal with a chromatic. You press the little button on the side and you get the notes in between, that is the entire pitch of the instrument, that’s why it costs four times as much as the other one.
So I went in to fix it, expecting to add a missing technique somewhere, and what I found instead was that the layout in my code was not a chromatic harmonica. It was not a harmonica at all. It was a C major scale going up one note per hole. C D E F G A B C D E F G, straight up, like somebody had typed a scale into an array and gone to lunch, which, in fairness, is exactly what happened, and the somebody was me.
A real 12-hole chromatic is solo tuned. It goes C E G C, then D F A B, and that four hole group repeats up the instrument for three octaves. That repeating is the whole point of it. That’s what makes one fingering work in every octave, that’s the thing you’re buying. Mine repeated nothing. Mine also stopped at A5 instead of C7, so fourteen of the thirty seven semitones between C4 and C7 weren’t reachable at all, on an instrument whose one job is reaching all of them.
Fourteen out of thirty seven. On the chromatic. The one that gets all the notes.
Now you’d think somebody would have noticed, and here is why nobody did, and it’s the part that actually bothers me.
Both of the chromatic charts I ship had the made up layout copied into them. Both of them. So they agreed with the code perfectly, and the code agreed with them, and everybody in there was consistent and confident and describing an instrument nobody owns.
One of those two charts, and I want you to appreciate this with me, one of those two charts is the lesson that teaches you the chromatic slide.
So if you had gone out and bought a real chromatic harmonica, an actual physical one, made of metal, by a company, and you’d sat down to learn the slide from my game, the hole numbers would have been wrong. Every one of them. And nothing anywhere would have told you why, and you would have assumed the problem was you, because when you’re learning an instrument you always assume the problem is you, and about nine times in ten you’re right, and this was the tenth time.
Both charts are re-fingered onto the real instrument now. The music didn’t change, and it couldn’t, because every event already recorded the pitch it sounds and those pitches were fine. It was only ever the hole numbers that were imaginary. So I re-resolved each event from its note instead of its hole: thirty three of them in Für Elise, sixteen in the lesson. Not one note moved.
The slide lesson does now teach ten slides instead of fourteen, because on a real solo tuned harmonica more of those notes just sit on a plain reed and don’t need the button. Which is fine. Ten slides is plenty of slides.
And the test that would have caught this doesn’t compare the charts to themselves, because as established they were extremely happy with themselves. It compares them against a tuning this codebase can actually build.
Two smaller ones, both in the notation strip along the top.
Accidentals were drawn per note instead of per bar. So if a tune leans on one altered note, and blues tunes do, a second position blues leans on its F# all day long, you got the same sharp redrawn in front of every single note. Which looks silly, but it’s worse than silly, because each one is about eleven pixels wide and an eighth note only has seventeen pixels to give in the first place.
They hold for the rest of the bar now, like they do on paper. And every note that cancels one gets a real natural sign, because just skipping the repeats would have left a later plain F in that bar reading as an F#, and I’d have gone from drawing something redundant to drawing something false, which is a worse trade than it sounds.
The staff itself was a fixed thirty four pixels per beat, and a notehead plus the accidental in front of it wants about twenty one, and a sixteenth note was getting eight and a half. They overlapped. Of course they overlapped. It works out the spacing from each song’s own density now, with a cap on it, because otherwise one busy bar shrinks how far ahead you can see down to about a bar and a half, and then you can’t read the thing at all.
That’s v0.0.11. Still 0.0.x, still early, still on GitHub, still, as of this week, no longer shipping an instrument that does not exist.
Today KDE releases a bugfix update to KDE Plasma 6, versioned 6.7.5.
Plasma 6.7 was released in June 2026 with many feature refinements and new modules to complete the desktop experience.
This release adds a month’s worth of new translations and fixes from KDE’s contributors. The bugfixes are typically small but important and include:
View full changelogIts been a minute since my last posts when I went over plasma-keyboard and its new diacritics feature, and the mega-sprint in Graz.
I've been busy with a whole lot of things, but here's a brief highlight:
I created a utility to check the health of KDE CI along with a web dashboard to visualize the results, and began making weekly updates on the state of all Plasma's CI health on the mailing list.
In the beginning we regularly had a dozen or more repos with CI failing on master, dozens of repos whose CI hadn't been run in months or in a few cases years, and 14% of repos configured to report failing tests in the MR view.
Now we usually never have more than 1 or 2 repo with failing CI in master any given week and even had a few weeks in a row with no failing CI, every Plasma repo runs its CI against master at least once a week to catch issues, and fully 94% of Plasma repos are configured to report failing tests in the MR view.
I consider this a massive success! 🎉🎉🎉
Still more that can be done to improve the reports and CI health, but kudos to everyone for helping trim the fat and keep our software stack healthy and reliable! 🍪
There have been requests for plasma-keyboard to support full-sized keyboard layouts, however there has been debate about if that is appropriate to have in plasma-keyboard; such a feature seems like it would be rather niche, while adding a fair amount of complexity and maintenance burden.
Full-sized layouts wouldn't add any benefit for the vast majority of users who want a way to type in a search, a text message, etc — it seems like a much rarer user who would want to perform desktop keyboard shortcuts, use vim in a terminal, change tty from their OSK instead of a real keyboard, etc.
The super talented Aleix created plasma-morekeys as a solution for those who want a full keyboard layout that simply emulates a real keyboard and can do all of the above mentioned things like keyboard shortcuts, and more.
This is intended as a test; it was put together quickly so those who need this feature can try it and provide feedback. If it proves successful then we can transition it to an official project, perhaps provide integration with plasma-keyboard to make choosing/using it seamless.
If you are one of the people with interest in a full-size keyboard layout for your OSK, please give it a try:
@merritt:kde.orgcurl -L -o /tmp/plasma-morekeys.flatpak "https://nextcloud.merritt.codes/s/x4gqrs596NPYarF/download" && flatpak install --user --or-update --bundle /tmp/plasma-morekeys.flatpak
Its just over a week until Akademy!! I'm looking forward to seeing a whole bunch of my KDE family again in Graz, and the chance to get some important work done together.
I have a bit of face blindness, so please don't be offended if I can't recognize everyone on sight! (I often rely on other cues like mannerisms, hair style, voice, etc)
I will try my best to be outgoing, but if I come across as a very anxious wallflower please know that I am friendly and super happy to see you all, and I appreciate the social butterflies pulling me into the mix! 😆
See you soon! 👋👋👋
I’m getting old (though, not as old as the image below), and I miss the good old days when using Linux was more difficult, but when every system in a Linux desktop session was simple.
This was before polkit, systemd, … Even before DBus and PulseAudio. All of these systems are cool and all, but I sometimes miss the simplicity of “everything can be a shell script”.
I’ve been playing around with something that made me investigate how the Plasma session is started, and if I can replicate it without significant issues with a simple shell script or something else.
It turns out it is not that difficult of a process, just a bit convoluted.
Your chosen display manager starts startplasma. A DBus
session is created and startplasmacompositor (and
kwin_wayland) is started. Then plasma_session
starts. And it starts kded6 and ksmserver.
There are a few other things that are started as well (like
kactivitymanagerd), but they are started
automagically by DBus when another component tries to use their
DBus API.
In the old days, there was just a simple shell script called
startkde which set the environment variables and started
all the needed processes for a working KDE (and later Plasma) session.
It wasn’t pretty, it wasn’t efficient, but it did what it needed to.
Se I decided to try to reimplement a rudimentary version of that script for the new Plasma.
These are the basic environment variables you’d want set before running a Plasma session (or other UI applications):
# XDG
export XDG_SESSION_TYPE=wayland
export XDG_CURRENT_DESKTOP=KDE
export XDG_SESSION_DESKTOP=KDE
# Qt
export QT_QPA_PLATFORM=wayland
export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_WAYLAND_RECONNECT=1
export QSG_RHI_BACKEND=vulkan
# KDE
export DESKTOP_SESSION=plasma
export KDE_FULL_SESSION=true
export KDE_SESSION_VERSION=6I placed this into a seaprate script called env.sh as it
is useful for testing to be able to initialize the same environment in a
shell outside of startkde.
Apart from these, if you have some custom installation paths for Qt
or KDE things, you should also set PATH,
XDG_DATA_DIRS, XDG_CONFIG_DIRS,
QT_PLUGIN_PATH, QML2_IMPORT_PATH and
QT_QUICK_CONTROLS_STYLE_PATH.
If you have any custom environment variables defined in
~/.config/plasma-workspace/env, you should add them here as
well (or source all the files from that directory).
For the main script, just source env.sh, run
dbus-update-activation-environment --all and start all the
session components mentioned above:
source env.sh
dbus-update-activation-environment --all
kwin_wayland --drm &
KWIN_PID=$!
sleep 1
export WAYLAND_DISPLAY=wayland-0
kactivitymanagerd &
ksmserver &
kded6 &
plasmashell &
krunner &
# other things you want started along with Plasma
wait $KWIN_PIDThe sleep 1 is evil and there are better ways to check
if wayland-0 became available, but this is a quick and
dirty script after all. And the original startkde script
also had some sleeps in it.
The only thing remaining is to create a session file that your
display manager can use, and you’re good to go
(/usr/share/wayland-session/shellscript-based-startplasma.desktop)):
...
Exec=dbus-run-session -- /path/to/the/script.sh
...This seems to work without important issues, it just skips the splash
screen which I can live without (wow, ksplashqml
is 15 years old…).
I didn’t test it for too long, as I quickly replaced this shell
script with a dinit-based setup, but more on that in the
next post.
