Every release has a killer feature. Qt 6.6 features the opposite - staying alive. This blog post describes work to make Qt clients more robust and seemlessly migrate between compositors, providing resistance against compositor crashes and more.

Prologue

Right now if you restart pulseaudio your sound might cut out, restart NetworkManager and you lose your wifi, restart an X11 window manager and your decorations disappear.

But within a second it's all back to normal exactly where you left off with everything recovering fine.

This isn't true for display servers. If X11 restarts you're back at the login prompt. All drafts lost, games unsaved, work wasted.

Past

For X11 this was unfixable; clients relied on memory stored by the Xserver, they made synchronous calls that were expected to return values, and multiple clients talked to multple clients.

This was a real problem in my early days of Linux, X11 would lock up frequently enough that most distributions had a shortcut key to restart the server and send you back to the login prompt.

It's less of an issue now as X11 has been in a lengthy period of feature freeze.

Present

Wayland makes it possible to fix all this. Memory allocations are client side, all operations are async, all protocols are designed that the compositor always has complete control.

Yet the current user-facing state is considerably worse:

• Compositors and displays servers are now the same process, doubling the space for errors

• Compositors are typically extensible with 3rd party plugins and scripts

• The wayland security model means the compositor absorbs even more functions from global shortcuts to screencasting and input-method handling

• The wayland ecosystem is not in a period of feature freeze with wayland protocols constantly evolving to cover missing features and new ideas.

  Even if there was a perfect compositor:

• 40% of kwin's crash bug reports are either upstream or downstream causes

• The current compositor developer experience is limited with developers having to relogin and restart their apps and development setup just to test their latest changes.

Plan

The solution for this? Instead of exiting when the compositor closes, simply...don't!

If we could connect to a new compositor we just need to send the right amount of information to bring it in sync and notify the application code of any changes to bring this in sync.

For Qt applications all this information is handled in the backend, in the Wayland Qt Platform Abstraction (QPA).

Qt already has to handle screens and input devices being removed, clipboards being revoked and drag and drops cancelled. Supporting a whole reset isn't introducing any new work, we just have to trigger all of these actions at once, then reconnect to the newly restored compositor and restore our contents.

Applications already have to support all of these events too as well as handle callbacks to redraw buffers. There's no changes needed at an application code level, it's all done as transparently as possible.

Handling OpenGL is a challenge, right now we don't have a way to keep that alive. Fortunately we put in lots of effort previously in supporting GPU resets throughout the Qt stack. The QtWayland backend fakes to the applications that a GPU reset has occured through the Qt abstractions.

For the majority of applications including all QtQuick users this happens automatically and flawlessly, building on the work that we put in previously.

Whilst the overall concepts might sound invasive, the final merge-request to support all of this for all Qt applications was fewer lines than supporting middle-click paste.

Almost no work needs doing on the compositor side. For a compositor there's no difference between a new client, and a client that was running previously reconnecting. The only big change we made within Kwin is having a helper process so the whole process can be seemless and race-free.

Proof

Path Forward

This post is about Qt, but the world is bigger than that. Not only does this technique work here, but we have pending patches for GTK, SDL and even XWayland, with key parts of SDL merged but disabled already.

The challenge for the other toolkits is we can't use the same OpenGL trick as Qt. They either lack GPU reset handling either at a toolkit level or within the applications.

Supporting OpenGL requires new infrastructure. We've tried from the start to get some infrastructure in place to allow this.It was clear that proposing library changes for client reconnection support was an uphill battle whilst being unproven in the wild.

After Qt6 is rolled out to a wider audience and shown to work reliably, we'll refocus efforts on pushing upstream changes to the other platforms.

Potential Perks

This isn't just about crashes. If support becomes mainstream there will be additional opportunities:

• We can easily upgrade to new features without having to log out and back. This is one of the reasons why kwin development is happening at such a rapid pace in recent months. We're not having to test in fake nested sessions or waste time logging in and setting up between changes.

• We can support multihead, running different compositors per group of outputs and move seemlessly between them.

• It's feasible to switch between compositors at runtime. With the application handling the reconnect logic, they can easily handle the case where compositor feature sets vary.

• Checkpoint restore in userspace, being able to suspend your application to disk and then pick up where you left off like nothing happened. It could never work for X applications, but with wayland reconnect support we can make it work.

Participating

More information about the long term goal this can be found at the kwin wiki, or each out to me directly if you want to add support.

Discuss this at discuss.kde.org.

Man, I wish politics were boring, but that is never going to happen. The only way a party can improve their popularity is by being seen as different and in some way better, so we will always have parties saying exactly that: That the others are wrong and that they are better.

However, in many cases there is actually a right and a wrong way to engage with a problem, so what will happen if one side wants to become popular with the worse solution? Well, lies, propaganda and disinformation of course!

But all of that shouldn't matter. If you have any opinion at all about what policies are good or bad, you can look up for yourself if a specific party worked for or against you in the past. But who wants to figure that out in their free time, really? I certainly don't, but I did it anyway because various elections in Germany are coming up and some parties have been actively working against what the KDE community stands for:

https://wordsmith.social/felixernst/deutscher-wahlkampf-aus-einer-kde-perspektive (German)

Yes, that article is only in German. I don't really want to translate it because I would need to provide a lot of local background knowledge as context. I am also already annoyed enough by Germany's political landscape that I wouldn't want to spend the time figuring out how to explain it to an international readership with varying backgrounds and severity of disinformation.

In any case, I wish all of you will be able to elect the party that is the least corrupt and whose actions (or lack thereof) are the least likely to kill innocent people. Happy voting!

This release introduces a wide variety of new features and several fixes.

New Animation Features

One new feature is the overshoot keyframe preset, with this comes the ability to edit the keyframe transition to go beyond the previously imposed limits.

Added support for "auto orienting" groups and layer, automatically aligning their rotation with the motion path.

Composition Overhaul

This is a major change of how compositions are handled internally, all compositions now share the same attributes and features, without having a "main" composition that dictates how other compositions should behave.

This fixes several minor inconsistencies that were previously caused by this distinction.

Additionally, when saving formats that support a single composition, Glaxnimate will automatically export the active composition, simplifying the exporting process and enhancing overall project management.

File Formats

The main new feature is support for Adobe After Effects Project files (.aep). This allows you to open animations created in AE directly within Glaxnimate.

While not all AE features are supported, most animations should work fine.

There have been several improvements to other file formats as well.

SVG

Now importing a non-animated SVG uses the same duration as the current composition, making it easier to use SVG files as assets.

Support has been added for importing SVG with animated path shapes, as well as animateMotion.

Animations within <defs> now are imported correctly.

Some other import improvements include fixes to group opacity, clip paths, anchor point detection, and detection of the start and end frames (The latter fix also applies to AVD import).

Exporting to SVG has received numerous improvements such as better star shape conversion, miter limit being correctly exported, removing unnecessary stroke shapes, and fixing export of precompositions with stretched time or time offsets.

Lottie

Lottie import has received several improvements as well.

Now Glaxnimate supports loading lottie files with radial gradient highlights, split positions, and auto-oriented layers. Zig zag import has also been improved.

There have also been fixes to dotLottie import, now images and custom metadata are properly supported.

Open / Save Improvements

Along with format support, this release introduces several quality of life improvements to the open / save flow.

Saving a file sets the default export path to the folder the file is saved to, this is to avoid having to select the folder again if you want to export the file into multiple formats.

When possible, backup files are saved in the same directory as the file being edited. Previously backup files were stored exclusively in the glaxnimate data directory, which made them more difficult to access.

Directly opening a static image file sets the animation to 1 second rather than 0.

A new setting has been introduced in the preferences dialog that allows toggling between the system native file dialog and the Qt widgets one.

There have also been improvements in the script API to handle import / export plugins: the new window.choose_option() method shows a dialog to display a selection from a list, and exception from I/O plugins now show in the script console.

More Accurate Animations

Animation rendering has received several fixes. Some files might look slightly different but now the animation appears as intended.

Easing curves for keyframes now offer more accurate timing. Some issues with the rendering of the last frame for layers and hold keyframes have been resolved, also the UI no longer makes frames outside the composition range available for selection.

There have been visual fixes for masks, trim path and offset path modifiers.

Minor Features

Added support for loading image assets from the web rather than limiting to local files.

Added built-in palettes with RAL and web colors and the palette selector has been improved to accommodate these large palettes.

Holding Ctrl now allows you to snap the transform position handle to the x or y axis for precise adjustments.

Finally some buttons in the advanced page of the trace dialog have been fixed.

Experimental Android APK

There's now an arm64 APK download for Android, providing you with the opportunity to experience Glaxnimate on your mobile device.

This is experimental so not all features might be available and the user interface hasn't been polished yet.

Today is my birthday but it’s also the day Francis got its first release. Francis is a pomodoro app, which was originally developed by Felipe Kinoshita. The Pomodoro Technique is a time management method developed by Francesco Cirillo in the late 1980s. It uses a kitchen timer to break work into intervals, typically 25 minutes in length, separated by short breaks.

The app is very simple and can be used as inspiration to develop your own Kirigami application.

Get Involved

If you are interested in helping, don’t hesitate to reach out in the Plasma Mobile matrix channel (#plasma-mobile:kde.org) and I will be happy to guide you.

I also regularly post about my progress on many KDE apps on my Mastodon account, so don’t hesitate to follow me there ;)

And in case you missed it, as a member of KDE’s fundraising working group, I need to remind you that KDE e.V., the non-profit behind the KDE community accepts donations.

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

The Qt 6 based KDE Frameworks 6 (KF6) development is ongoing since some time.

Already many things including Plasma and several applications, like Kate, have working KF6 based development versions.

KDE contributors did meet this week online for planning the final release time-frames.

We came up with this current plan:

Frameworks / Plasma/ Gear Release Schedule Plan

Following on from the last Akademy we checked where we were with our development progress in a meeting and settled on the following plan for all 3 major parts:

• In KDE Gear master will be open for Qt6 code to land for those ready to move. Not all apps need to port.

• The KDE Gear release will move by 2 months to allow for the extra time needed for testing initial Qt6 changes

• An Alpha will be made in November (a soft freeze in Plasma terms)

• Betas/RCs will be made throughout December and January (3 releases, 3 weeks apart)

• Final release of all 3 major parts in sync in February

Due to the delay of KDE Gear by an additional patch release of 23.08 will be made.

This is still up for discussion, but if no objections come up, we will see a triple release of a first stable KF6, KF6 based Plasma and KF6 based Gear next February.

There is still a lot to do, help is welcome!

Last weekend, I went to Freedom Not Fear 2023 in Brussels. Fnf is an unconference for and by European digital activists. It covers various topics, from the latest terrible European law (Chat Control) to discussing how to get more involved in our democracies.

I usually attend more technical conferences, and it was refreshing to participate in a conference where ethical and political discussions around digital rights were a central topic. It was an occasion to meet people from different backgrounds, from a Dutch politician (and self-proclaimed student for life), to a member of various organizations (e.g. Edri, NlNet, epicenter.works, Chatons, …) and journalists from Netzpolitik.

On Friday evening, aside from the welcome talk, we had a presentation from the European Data Protection Supervisor (Wojciech Wiewiórowski) about their work on deploying a Mastodon instance for the EU institutions and how the lack of subscribers makes it hard to justify continuing investing in it.

The presentation is on Peertube if someone wants to watch it.

During the weekend, we had an unconference-style conference where everyone could create a topic of discussion and present their work interactively. This worked very well.

Many participants were using Linux (and often with Plasma), but others were unaware of KDE. So I did a small lighting talk about the KDE community and presented a few utilities we create: Plasma, GCompris, Labplot, Krita, Merkuro and Itinerary. Time was limited, so I couldn’t show everything we were doing, but I hope this small list of software shows that we are covering many different types of software.

I prepared my slides the day before, as I saw some slots for lightning talks were still available, and the new KDE For pages were of great help. But it makes sense to have some slides provided by KDE Promo, which can then be reused and modified depending on the audience. I’ll bring up the idea at the next KDE Promo sprint in 2 weeks.

Aside from the weekend, which was packed with discussion, we went on Monday to the European Parlament and had a small presentation about how the European Parlament works. We also had the opportunity to ask Patrick Breyer from the German Pirate Party questions.

I enjoyed this conference and thank the organizers and Digital Courage for organizing this event and the two MEPs for using some of their travel allowance to bring many people to Brussels.

For a while now DrKonqi has a special developer notification system when used in combination with coredumpd. I just realized I never told anyone about it 😅 though.

It’s terribly simple: When used with coredumpd, parts of DrKonqi implicitly look at all crashes that pertain to your current user. Because of that it can also notify on all crashes, not just the KDE-related ones. Obviously it can’t report bugs or anything but sometimes, as a developer, it’s nice to know when things explode.

This is a purely opt-in feature and shouldn’t be enabled unless you know your way around the debugger GDB or really want to know about all the crashes.

To enable the feature simply add KDE_COREDUMP_NOTIFY=1 to your environment. For example using an environment.d file:

mkdir -p ~/.config/environment.d/
echo 'KDE_COREDUMP_NOTIFY=1' >> ~/.config/environment.d/50-$USER.conf

Rive is a popular tool for vector animations. While the editor itself is a closed source commercial product, there are FOSS implementations for the player runtime. basysKom has developed a QtQuick integration based on the rive-cpp library. This article introduces the project and its current state.

Continue reading Introducing the RiveQtQuickPlugin – Powerful Animations For Your QtQuick Applications at basysKom GmbH.

The other week the question came up how one can debug an application crash when the Windows Store crash tracking system is unable to produce a usable stack trace. Seemed a good enough opportunity to share some wisdom :)

Generally speaking in order to get a stack trace you first need a minidump. minidumps are kind of like core dumps on POSIX systems, well, except, mini. Acquiring that is should be your first goal.

There are a million ways to get a dump, I’ll highlight two of the easiest that I know of.

Partner Center Dumps

Ideally the Microsoft Partner Center will have a dump for you. You can find it usually where the stack trace is as well. To get access to KDE’s applications you need to be a KDE developer and file a sysadmin request. Once you have access you have to head from the Dashboard to Insights then navigate in the left hand pane to Health there use the drop-down to select the application you want to look at. This should give you every bit of information about the application health your heart could desire. You’ll probably also want to switch from viewing the last 72 hours to the last month, unless the application is particularly faulty of course.

Now all you need to do is click on the crash you want to look at, and not get too annoyed over the unknown crashes you can’t do anything about 😡.

At this point you should be able to find a stack trace link and an additional download link. Sometimes the download link is not there, I have no idea why but I’m sure it’s documented somewhere. The download link is what we are after, it contains the minidump along with some other metadata.

User-Mode Dumps

Now, sometimes the partner center is not able to help us for whatever reason. Maybe the download link is missing, maybe it just doesn’t show the crash we are after, maybe the dump on the partner center is useless. Who knows. In that case we need some help from the user. Thankfully it’s not too painful. They need to enable collection of user-mode dumps by creating the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps, which then causes the Windows Error Reporting to throw a minidump into %LOCALAPPDATA%\CrashDumps. The user then needs to reproduce the crash and obtain the dmp file from the aforementioned location.

Debug Symbols

Once you have obtained a minidump it’s time to find us some debug symbols. The sad truth here is that I can’t really help with that. Depending on how your application was built you’ll be able to get PDBs somehow hopefully. They will either float around as PDBs somewhere or at the very least will be available inside the .appxupload or .appxsym zip files. As a general best practice for KDE software I would advise that when you do a binary release to the Windows Store you also release the x86_64-dbg.7z file to download.kde.org so we can get the relevant PDBs when needed.

Tracing

Alright, I hope you had luck with finding your debug symbols, because now it’s time to do some tracing! Whee. You’ll need Microsoft Visual Studio. Any edition will do. File->Open->File... the minidump and you should be greeted by a nice overview of metadata about the crash.

First we’ll want to setup our debug symbols. For that you first want to place your PDBs somewhere in convenient in your file system. I’m lazy and usually just slap them on the Desktop. In Visual Studio you should find the option Set symbol paths in the right hand list of actions. The option opens the settings window on the correct page. Simply hit the ➕ and type out the path where you extracted the PDBs.

Once the symbol paths are set up you can hit Debug with Mixed and off the tracer goes. Slowly, because it needs to download a million symbols. But eventually you’ll arrive at your stack trace.

(nevermind my crazy setup, I was doing some wonky multi threaded debugging earlier and don’t know how to restore the UI 😅)

Hope this helps some!