Surprise! This blog post series has now been moved to blogs.kde.org so it's now open for others to participate and contribute! This week's post can be found at https://blogs.kde.org/2024/11/02/this-week-in-plasma-spoooooky-ooooooooom-notifications

That's probably where it should have been all along, as this work is much bigger than me. I'll remain the editor-in-chief for now, but do welcome contributions to help lighten the load.

Unfortunately, due to GDPR restrictions, I'm unable to migrate existing email subscribers to the new email digest over there. So if you'd like to re-subscribe to "This week in Plasma." head to https://newsletter.kde.org/subscription/form and re-subscribe.

I'll still be blogging here about KDE topics of interest to me and hopefully you as well, just not the weekly Plasma news. So I do hope you'll stick around.

02 Nov 2024 8:25am GMT

Welcome to the new home of "This Week in Plasma"! No longer is it a private personal thing on my (Nate Graham's) blog, but now it's a weekly series hosted here on KDE's infrastructure, open to anyone's participation and contribution! I'll remain the editor-in-chief for now, and welcome contributions via direct push to the relevant merge request on invent.kde.org. And after a post is published, if you find a typo or broken link, feel free to just fix it.

Anyway, this week we added a useful service to detect out-of-memory (OOM) conditions, did some UI polishing, and also a lot of bug-fixing! Check it out:

Notable New Features

When the system has run out of memory (OOM) and the kernel terminated an app, there's now a little service to detect this and show you a system notification explaining what happened, plus suggestions for what you can do about it in the future. (Harald Sitter, 6.3.0. Link)

Notable UI Improvements

The Emoji Selector app now does sub-string matching from the middle of words too, so you can find emojis more easily. (Eren Karakas, 6.2.3. Link)

The grouping indicator in the Task Manager widget (which looks like a little plus sign) is no longer always green; now it follows the current accent color! (Tem PQD, 6.3.0. Link)

Appropriate symbolic icons from will now be automatically substituted for apps' system tray icons - when they exist in the icon theme. If you'd like to extend this to more apps, figure out what icon name the app asks for, then create a symbolic version of it, append -symbolic to the name, and submit it to the Breeze Icons repo! (Marco Martin, 6.3.0. Link)

Notable Bug Fixes

Fixed a way that misbehaving XWayland-using apps could make KWin freeze. (Vlad Zahorodnii, 6.2.3. Link)

Fixed a bug causing notifications about modifier key changes (if you've turned them on) to not actually appear. (Nicolas Fella, 6.2.3. Link)

Fixed a bug in the Bluetooth pairing wizard that caused it to be annoying to enter digits. (Daniil-Viktor Ratkin, 6.2.3. Link)

Reviews on Discover's app pages now load properly when the app is accessed from the Home page, as opposed to after browsing or searching. (Aleix Pol Gonzalez, 6.2.3. Link)

Fixed the Task Manager widget's setting to reverse the direction that new tasks appear in so that it works as originally designed, and not only halfway there. (Michael Rivnak, 6.2.3. Link)

Fixed a bug that caused customized user avatars for other currently-logged-in users to not be displayed in the User Switcher widget. (Blazer Silving, 6.2.3. Link)

Fixed a bug causing the "Show Logout Screen" item in the desktop context menu to not show enough items if you had customized the "default logout option" in the past, back when we offered that as a user-facing setting. (Nate Graham, 6.2.3 Link)

With global animations set to "instant", window thumbnails in KWin's Desktop Grid effect are no longer too small. (Niccolò Venerandi, 6.2.3. Link)

When you've got the Application Dashboard widget set up with an icon naming style that causes the text to be long and get elided, hovering over the icon now shows a tooltip with the correct full text in it. (Tomislav Pap, 6.2.3. Link)

Fixed a case where KWin could crash when moving certain drawing tablet pens to the surface of the pad. (Vlad Zahorodnii, 6.3.0. Link)

Fixed an issue that caused XWayland-using apps to resize in a janky and jumpy manner. (Vlad Zahorodnii, 6.3.0. Link, see detailed blog post)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE - you are not a number or a cog in a machine!

You don't have to be a programmer, either. Many other opportunities exist:

• Filter and confirm bug reports, maybe even identify their root cause
• Contribute designs for wallpapers, icons, and app interfaces
• Design and maintain websites
• Translate user interface text items into your own language
• Promote KDE in your local community
• …And a ton more things!

You can also help us by donating to our yearly fundraiser! Any monetary contribution - however small - will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

02 Nov 2024 4:00am GMT

Let's go for my web review for the week 2024-44.

What You Can Learn from Just Seven Pages by Hannah Arendt

Tags: tech, philosophy, history, politics

A very precious philosopher from the 20th century. Her texts are still very precious and resonate today. In this piece it's focusing about tech relevant excerpts, she had plenty to say about today's politics as well.

https://www.honest-broker.com/p/what-you-can-learn-from-just-seven

The Open Source AI Definition

Tags: tech, foss, ai, machine-learning

Nice initiative from the OSI. It is timely, such a definition was surely needed. The data information part seems fairly weak though… for sure you could make a system which doesn't respect the four freedoms that way.

https://opensource.org/ai/open-source-ai-definition

Does Open Source AI really exist?

Tags: tech, foss, ai, machine-learning

Like me, you find the Open Source AI Definition weak on the training data information side? You'd be right and there's a reason for it… it's probably hiding quite some open washing for the larger models. This is a good explanation of the motives and consequences.

https://tante.cc/2024/10/16/does-open-source-ai-really-exist/

Platform Strategy and Its Discontents

Tags: tech, web, mobile, react, framework, criticism

This is definitely true. As long as web frontends are dominated by large frameworks, the web will always have subpar experience on mobile. And the solution isn't going to come from the mobile providers too happy to gatekeep their app store.

https://infrequently.org/2024/10/platforms-are-competitions/#fn-failure-on-repeat-2

Matrix 2.0 Is Here!

Tags: tech, matrix, protocols

This is definitely getting there in terms of performance and usability. The mobile clients seem mature enough, just need the desktop clients to catch up before this becomes really something I'd feel confident enough to recommend and push for.

https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/

What's New in POSIX 2024

Tags: tech, unix, posix

It's nice to see the standard still moves. Some of the additions are definitely welcome.

https://blog.toast.cafe/posix2024-xcu

Australia/Lord_Howe is the weirdest timezone

Tags: tech, time, culture, internationalization

Time management and timezones are definitely complicated. In a way it's culture colliding with computers and localisation… it can't be simple.

https://ssoready.com/blog/engineering/truths-programmers-timezones/

Improving SSH's security with SSHFP DNS records

Tags: tech, tools, ssh, dns, security

Nice technique for automating the verification of SSH host keys. It'd be nice to see wider adoption.

https://blog.apnic.net/2022/12/02/improving-sshs-security-with-sshfp-dns-records/

Introducing zizmor: now you can have beautiful clean workflows

Tags: tech, github, ci, security, tools

Definitely an interesting tool. GitHub Actions workflow aren't easy to setup while ensuring they're secure, having a tool analyzing them for issues can only help.

https://blog.yossarian.net/2024/10/27/Now-you-can-have-beautiful-clean-workflows

Toward safe transmutation in Rust

Tags: tech, rust, type-systems, memory

Interesting progress on safe type casting in Rust. This should bring nice zero copy parsing of binary data in some cases.

https://lwn.net/SubscriberLink/994334/5e1f97f08916b494/

Lessons learned from a successful Rust rewrite

Tags: tech, c++, rust, legacy

This is a good view of what you're getting into with the "rewrite it in Rust" knee-jerk reaction.

https://gaultier.github.io/blog/lessons_learned_from_a_successful_rust_rewrite.html

Vector Databases Are the Wrong Abstraction

Tags: tech, postgresql, databases, ai, machine-learning, language

I definitely like the approach of having vectorisation in the RDBMS directly. This is one less moving part, less complexity at the application level to synchronize everything together. In this case it's a Postgres extension.

https://www.timescale.com/blog/vector-databases-are-the-wrong-abstraction/

Database Remote-Copy Tool For SQLite

Tags: tech, sqlite, databases, tools

Interesting, there's now an official tool to replicate sqlite databases. It's still early days, we'll see which features it'll get.

https://sqlite.org/rsync.html

How to profile a performance issue using Spring Boot profiling tools

Tags: tech, java, spring, profiling

A quick tour of the available tools to profile Spring Boot applications.

https://foojay.io/today/how-to-profile-a-performance-issue-using-spring-boot-profiling-tools/

Working with stacked branches in Git is easier with -update-refs

Tags: tech, git, tools

Yet another Git option I missed. This is definitely useful, I'll try it out.

https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/

pygfx

Tags: tech, python, 3d, webgpu, data-visualization

Looks like a very interesting Python library to build interactive 3d visualizations.

https://docs.pygfx.org/stable/index.html

Rudimentary 3D on the 2D HTML Canvas

Tags: tech, 2d, 3d, graphics, mathematics

Ever wondered how to simulate 3D from 2D based primitives? Here is a nice experiment explaining how to approach it.

https://www.charlespetzold.com/blog/2024/09/Rudimentary-3D-on-the-2D-HTML-Canvas.html

Classic 3D videogame shadow techniques

Tags: tests, 3d, graphics

A nice list of the techniques used to render shadows in games.

https://30fps.net/pages/videogame-shadows/

On Crafting Painterly Shaders

Tags: tech, 3d, graphics, shader

Very nice deep dive into a post-processing shader to create a painted scene effect.

https://blog.maximeheckel.com/posts/on-crafting-painterly-shaders/?ck_subscriber_id=2669647738

The Basics

Tags: tech, craftsmanship, learning, career

Indeed, those are fundamental traits to make sure you learn and make progress on your journey.

https://registerspill.thorstenball.com/p/the-basics

Background Work - by Kent Beck

Tags: tech, learning, career, craftsmanship

Another excellent piece from Kent Beck, he's right that the real differentiator in our profession is about digging deep on topics, seeing them through even if that's on the side. Curiosity is a key trait.

https://tidyfirst.substack.com/p/background-work

the death of the architect

Tags: tech, agile, architecture, history

Good explanation on how the agile movement scaled down about design over time in its literature. It's probably its biggest failure. The good thing is that the pendulum is starting to swing in the other direction a bit (that's probably why Beck is now working on a book series on software design).

https://explaining.software/archive/the-death-of-the-architect/

How to make Product give a shit about your architecture proposal

Tags: tech, quality, product-management, project-management

This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.

https://gieseanw.wordpress.com/2024/10/09/how-to-make-product-give-a-shit-about-your-architecture-proposal/

How to not be a prioritization machine

Tags: tech, project-management, product-management, decision-making

Interesting guidelines idea to help teams manage the priorities themselves. It's written in the context of a product manager but I think it is lightweight and generic enough to apply in other contexts.

https://productmanagers.substack.com/p/how-to-not-be-a-prioritization-machine

We Fell For The Oldest Lie On The Internet

Tags: science, complexity

It's sometimes extremely difficult to get to the original source of a scientific claim. Our corpus of science is so large and complex now that finding where a claim comes from can be a daunting task.

https://www.youtube.com/watch?v=bgo7rm5Maqg

Changes in primary visual and auditory cortex of blind and sighted adults following 10 weeks of click-based echolocation training | Cerebral Cortex | Oxford Academic

Tags: science, neuroscience

This is an amazing example of the brain plasticity. It's also great to have a patch for increased quality of life with a training of only a few weeks.

https://academic.oup.com/cercor/article/34/6/bhae239/7696241?login=false

Bye for now!

01 Nov 2024 5:18pm GMT

The Qt Quick 3D project was first announced and released in 2019. Since then, it has seen numerous enhancements. We have concentrated on boosting performance, introducing new features, and expanding the module's capabilities.

01 Nov 2024 8:00am GMT

I had previously mentioned efforts on bringing public emergency and weather alerts to free software and free infrastructure, which was also my initial motivation to work on push notifications. With that moving forward it's time to explain a bit more what's happening there.

FOSS Public Alert Server

As part of the initial push notification work I had written a simple prototype server which aggregates alerts from about a hundred countries and allows clients to subscribe to be notified about alerts in a given area of interest.

With the push notification client and server parts for KDE released and deployed, that's now the next thing to tackle.

After teaming up with FOSS Warn (a free alternative to the proprietary emergency and weather alert apps in Germany), who need the same kind of infrastructure there's now even NLnet funding to turn this into production-ready software.

Work is going to happen in this repository on KDE's Gitlab instance, and can be followed on this Mastodon account.

Common Alerting Protocol (CAP)

For this to scale globally we need standardized data models, data formats and protocols. And thankfully those exist in form of OASIS' Common Alerting Protocol (CAP) since many years and are widely in use.

CAP describes an XML format for alert messages, covering categorization, severity, certainty, urgency, affected area, and multi-lingual descriptions and instructions.

Build on top of that are CAP feeds, which are basically RSS or Atom feeds of CAP alert messages.

There's also a bunch of national- or agency-specific profiles which for example define additional information elements or specify the use of existing fields more precisely for their use-case.

From a technical point of view none of that is particularly challenging, we already have support for CAP alerts in KWeatherCore for example.

CAP is widespread for internal use in various international, national or sub-national emergency warning systems, for connecting alerting authorities with e.g. media broadcast or mobile network providers. In many countries CAP feeds are also publicly available, which is the interesting part for us here.

CAP Workshop

After having gotten in touch with other people working in this area we got invited to the CAP Workshop that happened last week, a rather unassuming name for a three day international conference with national delegations from more than 120 countries, several UN agencies and NGOs like the International Red Cross/Crescent, and quite a bit more formal than what we are used to from other events.

Unfortunately I couldn't be there in person and only followed this online, but even that provided quite some interesting insights.

• OASIS' work on extended event codes, which should help with better display and filtering of alerts in client applications.
• Several talks covered the "usability" of alerts, ie. how to word/present warnings so that they are understood by everyone and so that they result in the intended reaction. Much of this is in the hands of the alert issuers, but client software can help here as well, e.g. regarding accessibility (TTS, both visual and audible notifications, translations and understandable language in general, etc).
• Google showed the various places where they integrate alerts in their products: displayed on maps, discoverable via search, location-dependent push notifications, integrated with weather forecasts and in routing before entering an affected area. Can be inspiration for what we could do as well.
• A talk presented work on Mexico's earthquake early warning system. As earthquakes can't be predicted this uses the fact that an alert can outrace the shockwave and thus might still reach people further away in time (same as tsunami warnings work, just at a much shorter timescale). Their estimate from a simulation of past earthquakes was 10 seconds making a difference of 10k lives. That's a level of responsiveness our current CAP feed polling approach is not going to be able to reach, this would need direct listening to the alert radio signals.
• There's several CAP feeds that aren't publicly available yet, whenever such a case came up there was push for changing that in the following Q&A session. Good, we need that.

How you can help

There's plenty of things to do here. On the software development side there's getting the server code production ready and deployed, building monitoring tools for that and turning the demo app into a reuable client library and integrating that in places where it makes sense.

Equally important though is finding more CAP feeds and in some cases additional data sets to resolve area codes used in the alerts to geographic polygons. This is something that often needs local knowledge and understanding the local languages. And where there are no CAP feeds yet, nagging your local authorities to change that also helps.

We should soon get a dedicated Matrix channel for coordinating this, and we'll be at 38C3 and FOSDEM 2025 if you want to talk about this in person.

01 Nov 2024 6:30am GMT

We are happy to announce the release of Qt Creator 15 Beta2!

31 Oct 2024 12:55pm GMT

In an era where digital security is paramount, the European Union is taking steps to improve cybersecurity legislation with the introduction of the European Union Cyber Resilience Act (CRA). As the European Union has now adopted the CRA, Qt Group continues to work towards making our products CRA compliant and supporting our customers with their compliancy.

31 Oct 2024 10:26am GMT

We just released CXX-Qt version 0.7!

CXX-Qt is a set of Rust crates for creating bidirectional Rust ⇄ C++ bindings with Qt. It supports integrating Rust into C++ applications using CMake or building Rust applications with Cargo. CXX-Qt provides tools for implementing QObject subclasses in Rust that can be used from C++, QML, and JavaScript.

For 0.7, we have stabilized the cxx-qt bridge macro API and there have been many internal refactors to ensure that we have a consistent baseline to support going forward. We encourage developers to reach out if they find any unclear areas or missing features, to help us ensure a roadmap for them, as this may be the final time we can adapt the API. In the next releases, we're looking towards stabilizing the cxx-qt-build and getting the cxx-qt-lib APIs ready for 1.0.

Check out the new release through the usual channels:

• The CXX-Qt book
• The CXX-Qt documentation
• The CXX-Qt-lib documentation
• Our Github repository

Some of the most notable developer-facing changes:

Stabilized #[cxx_qt::bridge] macro

CXX-Qt 0.7 reaches a major milestone by stabilizing the bridge macro that is at the heart of CXX-Qt. You can now depend on your CXX-Qt bridges to remain compatible with future CXX-Qt versions. As we're still pre-1.0, we may still introduce very minor breaking changes to fix critical bugs in the edge-cases of the API, but the vast majority of bridges should remain compatible with future versions.

This stabilization is also explicitly limited to the bridge API itself. Breaking changes may still occur in e.g. cxx-qt-lib, cxx-qt-build, and cxx-qt-cmake. We plan to stabilize those crates in the next releases.

Naming Changes

The handling of names internally has been refactored to ensure consistency across all usages. During this process, implicit automatic case conversion has been removed, so cxx_name and rust_name are now used to specify differing Rust and C++ names. Since the automatic case conversion is useful, it can be explicitly enabled using per extern block attributes auto_cxx_name and auto_rust_name, while still complimenting CXX. For more details on how these attributes can be used, visit the attributes page in the CXX-Qt book.

// with 0.6 implicit automatic case conversion
#[cxx_qt::bridge]
mod ffi {
unsafe extern "RustQt" {
#[qobject]
#[qproperty(i32, my_number) // myNumber in C++
type MyObject = super::MyObjectRust;
fn my_method(self: &MyObject); // myMethod in C++
}
}
// with 0.7 cxx_name / rust_name
#[cxx_qt::bridge]
mod ffi {
unsafe extern "RustQt" {
#[qobject]
#[qproperty(i32, my_number, cxx_name = "myNumber")
type MyObject = super::MyObjectRust;
#[cxx_name = "myMethod"]
fn my_method(self: &MyObject);
}
}
// with 0.7 auto_cxx_name / auto_rust_name
#[cxx_qt::bridge]
mod ffi {
#[auto_cxx_name] // <-- enables automatic cxx_name generation within the `extern "RustQt"` block
unsafe extern "RustQt" {
#[qobject]
#[qproperty(i32, my_number) // myNumber in C++
type MyObject = super::MyObjectRust;
fn my_method(self: &MyObject); // myMethod in C++
}
}

cxx_file_stem Removal

In previous releases, the output filename of generated C++ files used the cxx_file_stem attribute of the CXX-Qt bridge. This has been changed to use the filename of the Rust source file including the directory structure.

Previously, the code below would generate a C++ header path of my_file.cxxqt.h. After the changes, the cxx_file_stem must be removed and the generated C++ header path changes to crate-name/src/my_bridge.cxxqt.h. This follows a similar pattern to CXX.

// crate-name/src/my_bridge.rs
// with 0.6 a file stem was specified
#[cxx_qt::bridge(cxx_file_stem = "my_file")]
mod ffi {
...
}
// with 0.7 the file path is used
#[cxx_qt::bridge]
mod ffi {
...
}

Build System Changes

The internals of the build system have changed so that dependencies are automatically detected and configured by cxx-qt-build, libraries can pass build information to cxx-qt-build, and a CXX-Qt CMake module is now available providing convenience wrappers around corrosion. This means that the cxx-qt-lib-headers crate has been removed and only cxx-qt-lib is required. With these changes, there is now no need for the -header crates that existed before. Previously, some features were enabled by default in cxx-qt-lib. Now these are all opt-in. We have provided full and qt_full as convenience to enable all features; however, we would recommend opting in to the specific features you need.

We hope to improve the API of cxx-qt-build in the next cycle to match the internal changes and become more modular.

Further Improvements

CXX-Qt can now be successfully built for WASM, with documented steps available in the book and CI builds for WASM to ensure continued support.

Locking generation on the C++ side for all methods has been removed, which simplifies generation and improves performance. Using queue from cxx_qt::CxxQtThread is still safe, as it provides locking, but it is up to the developer to avoid incorrect multi-threading in C++ code (as in the CXX crate). Note that Qt generally works well here, with the signal/slot mechanism working safely across threads.

As with most releases, there are more Qt types wrapped in cxx-qt-lib and various other changes are detailed in the CHANGELOG.

Make sure to subscribe to the KDAB YouTube channel, where we'll post more videos on CXX-Qt in the coming weeks.

Thanks to all of our contributors that helped us with this release:

• Ben Ford
• Laurent Montel
• Matt Aber
• knox (aka @knoxfighter)
• Be Wilson
• Joshua Goins
• Alessandro Ambrosano
• Alexander Kiselev
• Alois Wohlschlager
• Darshan Phaldesai
• Jacob Alexander
• Sander Vocke

The post CXX-Qt 0.7 Release appeared first on KDAB.

31 Oct 2024 8:30am GMT

KDE's yearly fundraiser is now live, with the theme of spooooky proprietary software. Go check it out - no, really! It's great!

I think this one absolutely nails it, because the stories there are relatable. They describe common problems with proprietary software most of us have personally experienced in our journeys to the FOSS world, and how FOSS fixes it.

Let me share some of mine:

• When I was a kid, I liked to make movies with my friends and add wacky special effects using a program called AlamDV. I even bought a license to it! After a year, it broke and the developer released version 2, which I dutifully also bought a new license for. Unfortunately, none of my AlamDV 1 projects opened in it. They were lost to the wind.
• Similarly, I also used Apple's iMovie editing app. At a certain point, they changed it completely to have a totally different UI and no longer open old projects. Still a kid, I never managed to figure out the new UI and all my old projects were lost forever.
• A lot of the digital art I made as a kid was saved in Apple's .pict file format, which even they eventually dropped support for. When I moved to Linux, I had to write a script to open these files individually and take screenshots of them in order to not lose them forever.
• I've been able to consistently recycle older computers and keep them relevant with Plasma. Both of my kids have perfectly serviceable hand-me-down computers revitalized with Fedora KDE. My wife's old 10 year-old laptop is a testbed for KDE Linux.
• My sister-in-law just last weekend was complaining to me about AI in Photoshop, and was very receptive to the idea of ditching Microsoft and Adobe software entirely. It's a big turn-off to artists.

This stuff is real, and the work we do has significant impact. It's not just a toy for nerds. It's not a basement science project for bored tinkerers. It's the way computers should be, and can be if enough of us donate our skills, time, and money towards the goal.

How will the fundraised money be used? Principally, to help KDE e.V. balance its budget and stop operating at a loss (about -110k last year, projected -70k this year) due to the legal requirement to spend down large lump-sum donations in a timely manner. We can sustain this level of deficit spending for a few more years, but of course would prefer not to. It's been a tough environment for nonprofits, and you might have heard that the GNOME Foundation recently ran into financial trouble trouble had to cut back. We want to avoid that! The sooner we're operating at a surplus again, the sooner we can expand our sponsorship of engineering work beyond its current level.

So go donate today, and make a difference in the most important movement in software today!

30 Oct 2024 9:55pm GMT

Fedora 41 has been released! 🎉 So let's see what comes in this new release for the Fedora Atomic Desktops variants (Silverblue, Kinoite, Sway Atomic and Budgie Atomic).

bootupd enabled by default for UEFI systems (BIOS coming soon)

After a long wait and a lot of work and testing, bootloader updates are finally enabled by default for Atomic Desktops.

For now, only UEFI systems will see their bootloader automatically updated on boot as it is the safest option. Automatic updates for classic BIOS systems will be enabled in the upcoming weeks.

If you encounter issues when updating old systems, take a look at the Manual action needed to resolve boot failure for Fedora Atomic Desktops and Fedora IoT Fedora Magazine article which includes instructions to manually update UEFI systems.

Once you are on Fedora 41, there is nothing more to do.

See the Enable bootupd for Fedora Atomic Desktops and Fedora IoT change request and the tracking issue atomic-desktops-sig#1.

First step towards Bootable Containers: dnf5 and bootc

The next major evolution for the Atomic Desktops will be to transition to Bootable Containers.

We have established a roadmap (atomic-desktops-sig#26) and for Fedora 41, we added dnf5 and bootc to the Bootable Container images of Atomic Desktops.

Those images are currently built in the Fedora infrastructure (example) but not pushed to the container registry.

The images currently available on quay.io/fedora (Silverblue, Kinoite, etc.) are mirrored from the ostree repository and thus do not yet include dnf5 and bootc.

Once releng#12142 has been completed, they will be replaced by the Bootable Container images.

In the mean time, you can take a look at the unofficial images (see the Changes in unofficial images section below).

See the DNF and bootc in Image Mode Fedora variants change request and the tracking issue atomic-desktops-sig#48

What's new in Silverblue

GNOME 47

Fedora Silverblue comes with the latest GNOME 47 release.

For more details about the changes that alongside GNOME 47, see What's new in Fedora Workstation 41 on the Fedora Magazine and Fedora Workstation development update - Artificial Intelligence edition from Christian F.K. Schaller.

Ptyxis as default terminal application

Ptyxis is a terminal for GNOME with first-class support for containers, and thus works really well with Toolbx (and Distrobox). This is now the default terminal app and it brings features such as native support for light/dark mode and user-customizable keyboard shortcuts.

See Ptyxis' website.

Wayland only

Fedora Silverblue is now Wayland only by default. The packages needed for the X11 session will remain available in the repositories maintained by the GNOME SIG and may be overlayed on Silverblue systems that require them.

See the Wayland-only GNOME Workstation Media change request and the tracking issue: atomic-desktops-sig#41.

What's new in Kinoite

KDE Plasma 6.2

Fedora Kinoite ships with Plasma 6.2, Frameworks 6.7 and Gear 24.08.

See also What's New in Fedora KDE 41? on the Fedora Magazine.

Kinoite Mobile

Kinoite Mobile is currently only provided as unofficial container images. See the Changes in unofficial images section below.

See the KDE Plasma Mobile Spin and Fedora Kinoite Mobile change request.

What's new in Sway Atomic

Fedora Sway Atomic comes with the latest 1.10 Sway release.

What's new in Budgie Atomic

Nothing specific this release. The team is working on Wayland support.

Changes in unofficial images

Until we complete the work needed in the Fedora infrastructure to build and push official container images for the Atomic Desktops (see releng#12142), I am providing unofficial builds of those. They are built on GitLab.com CI runners, use the official Fedora packages and the same sources as the official images.

You can find the configuration and list on gitlab.com/fedora/ostree/ci-test and the container images at quay.io/organization/fedora-ostree-desktops.

New unofficial images: Kinoite Mobile & COSMIC Atomic

With Fedora 41, we are now building two new unofficial images: Kinoite Mobile and COSMIC Atomic. They join our other unofficial images: XFCE Atomic and LXQt Atomic.

See How to make a new rpm-ostree desktop variant in Fedora? if you are interested in making those images official Fedora ones.

See the KDE Plasma Mobile Spin and Fedora Kinoite Mobile change request and the Fedora COSMIC Desktop Environment Special Interest Group (SIG) page.

Renaming the Sericea and Onyx unofficial images to Sway Atomic and Budgie Atomic

If you are using the Sericea or Onyx container images, please migrate to the new Atomic names for Sericea & Onyx (sway-atomic and budgie-atomic) as I will remove the images published under the old name soon, likely before Fedora 42.

We will likely rename the official container images as well.

Smaller changes common to all desktops

Unprivileged updates

The polkit policy controlling access to the rpm-ostree daemon has been updated to:

• Enable users to update the system without having elevated privileges or typing a password. Note that this change only applies to system updates and repository meta updates; no other operations.
• Reduce access to the most privileged operations (such as changing the kernel arguments, or rebasing to another image) of rpm-ostree for administrators to avoid mistakes. Only the following operations will remain password-less to match the behavior of package mode Fedora with the dnf command:
  • install and uninstall packages
  • upgrade the image
  • rollback the image
  • cancel transactions
  • cleanup deployment

See the Unprivileged updates for Fedora Atomic Desktops change request and the tracking issue atomic-desktops-sig#7.

"Alternatives" work again

The alternatives command (alternatives(8)) is now working on Atomic Desktops.

See the tracking issue atomic-desktops-sig#51 for more details and documentation.

Fixes for LUKS unlock via TPM

Support for unlokcing a LUKS partition with the TPM is now included in the initramfs.

See the tracking issue atomic-desktops-sig#33 and the in progress documentation silverblue-docs#176.

Universal Blue, Bluefin, Bazzite and Aurora

Our friends in the Universal Blue project have prepared the update to Fedora 41 already. For Bazzite, you can find all the details in Bazzite F41 Update: New Kernel, MSI Claw Improvements, VRR Fixes, Better Changelogs, GNOME 47 & More.

For Bluefin (and similarly for Aurora), see Bluefin GTS is now based on Fedora 40.

I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA proprietary drivers, extra media codec, etc.).

What's next

We have made lot of progress since the last time, thus this section is going to be more exciting!

Roadmap to Bootable Containers

As I mentionned in First step towards Bootable Containers: dnf5 and bootc, the next major evolution for the Atomic Desktops will be to transition to Bootable Containers. See also the Fedora bootc documentation.

We have established a roadmap (atomic-desktops-sig#26) and we need your help to make this a smooth transition for all of our existing users.

composefs

Moving to composefs is one of the items on the roadmap to Bootable Containers. composefs is the next step for ostree based systems and will enable us to provide better integrity and security in the future.

For Fedora 41, we moved Fedora CoreOS and Fedora IoT to composefs.

For the Atomic Desktops, this is planned for Fedora 42 as we still have a few issues to resolve. See the Enabling composefs by default for Atomic Desktops change request and the tracking issue atomic-desktops-sig#35.

Custom keyboard layout set on installation

This fix is important for setups where the root disk is encryptd with LUKS and the user is asked a passphrase on boot. Right now, the keyboard layout is not remembered and defaults to the US QWERTY layout. Unfortunately this fix did not land in time for Fedora 41 but this will be part of the Fedora 42 installations ISOs. Help us test this by installing systems from a Rawhide ISO to confirm that this issue is fixed.

If you are impacted by this issue, see the tracking issue atomic-desktops-sig#6 for the manual workarounds.

Unifying the Atomic Desktops documentation

We would like to unify the documentation for the Fedora Atomic Desktops into a single one instead of having per desktop environments docs which are mostly duplicate of one another and need to be constantly synced.

See the tracking issue atomic-desktops-sig#10.

Where to reach us

We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.

• Atomic Desktops SIG: Issue tracker (gitlab.com/fedora/ostree/sig), #atomic-desktops:fedoraproject.org
• Silverblue: Workstation Working Group, #silverblue:fedoraproject.org
• Kinoite: KDE SIG, #kinoite:fedoraproject.org
• Sway Atomic: Sway SIG, #sway:fedoraproject.org
• Budgie Atomic: Budgie SIG, #budgie:fedoraproject.org

29 Oct 2024 11:00pm GMT

I've had my Creality CR-6 SE for quite some while now and it's worked very well. I've even moved with it a couple of times. However, it seems that now was the time for it to give up the ghost, as the extruder casing developed a crack. Apparently something not completely uncommon.

So I searched the internet for spare parts before I realized that this is a common failure mode and that there are all-metal replacements. A few clicks later, I had one ordered from Amazon. I took a chance and ordered one for CR-10, as it looked like it would fit from the photos, and it did (phew). Here is a link to the one I got: link.

The installation went smooth. The only tricky part was getting the threads of the screw being pushed by the spring right. The spring is quite strong, so it is really a three hand operation in the area where my fingers have a hard time fitting. Having done that, it seems like it just work straight out of the box.

The print has been going on for a couple of hours now, and there has been no hickups. Big shout-out to OctoPrint while I'm at it. Being able to keep an eye on things without having to sit next to the printer is just great (and not having to fiddle around with SD-cards is also really nice).

29 Oct 2024 11:47am GMT

On releasing the latest version of Krita in our Android/ChromeOS beta program, we discovered, too, late that there was a problem that could prevent Krita from starting.

Since the Google Play Store Console does not allow revering a release to an earlier version, we are now urgently working on a fix which we will release as soon as possible.

Our apologies for the inconvience.

The currentl nightly builds for Android work again, with some limitations:

• take care removing the store version of Krita does not remove the application data: your artwork could be lost.
• in the Nightly builds you need to install any brush presets separately

You can get the night builds here: Krita Next Nightly Builds. You will need to select the package that is right for the architecture of your device.

Installing the nightly builds requires enabling developer mode on your device and needs considerable technical insight.

If you do not feel comfortable with this, please wait until the new official release lands in the play store in a about two days.

29 Oct 2024 12:00am GMT

Ruqola 2.3.1 is a feature and bugfix release of the Rocket.chat app.

New features:

• Use "view-conversation-balloon-symbolic" icon when we have private conversation with multi users
• Add version in market application information
• Fix reset password
• Fix mouse position when QT_SCREEN_SCALE_FACTORS != 1
• Add missing icons
• Fix create topic when creating teams
• Fix discussion count information
• Remove @ or # when we search user/channel
• Fix edit message logic

URL: https://download.kde.org/stable/ruqola/
Source: ruqola-2.3.1.tar.xz
SHA256: 99356ec689473cd5bfaca7f8db79ed5978efa8b3427577ba7b35c1b3714d5fcb
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
https://jriddell.org/jriddell.pgp

29 Oct 2024 12:00am GMT

Getting There!

Wow! What a trip! 20 hours across 2 flights, 2 hours on the train with travel buddies Nate Graham and Bhushan Shah, and several bus "adventures" with Nate Graham to our hotel. The hotel... Let's not go into too much detail, suffice to say it was an absolute mess.

This being my first Akademy in person it was a very anxious experience getting there, but with global roaming on my phone to keep communication flowing and a few travel buddies it was certainly made much better!

But once we were settled in and unpacked, it was off to the first event!

The Welcome Event!

Wow, was it chaos once all the people showed up, but amazing to see so many KDE users and developers! A few locals even popped their head in, confused by the packed out venue. We thankfully managed to get a ride in Adriaan de Groot's smooth E.V to the venue and found a few others after parking.

The place had a great vibe and the free drinks and snack courtesy of KDE went down a treat! I quickly connected to the free Wi-Fi, spun up some translations of the menu and grabbed the Mexican Fries with guacamole, tomatoes and onions. It was amazing with a few drinks to wash it all down!

On to the main event!

Saturday Talks!

Having the talks start a little later was great as it meant we didn't have to get up early and get rushing out the door!

Adriaan also bought Stroopwafels with him! So delicious!

Only Hackers Will Survive

The first talk (barring the brief opening by the Akademy team) was right into the thick of it, and it was about circular economies, electronic waste and how we, the hackers, have the right mindset to keep things working well beyond manufacturers expected lifetimes. Whether they be limited by lack of software updates or pushed out of the market by ever more demanding software performance requirements.

The scenes of landfills around the globe on display with people in Third World countries sorting through them to reclaim precious metals on display to really bring home the true impact. Here's hoping KDE's software and projects can help with this, especially with the Blue Angel Certification. I am really hoping to see Plasma Mobile continue to take charge in this area, where mobile devices are often discarded rapidly in favour of the newest shiniest thing.

Goals Wrap Up!

Every two years, KDE chooses new goals to focus on to make KDE's software better for all. At this year's Akademy it was time to review the goals outcomes for the last two years.

Carl Schwan went through his accessibility goal outcomes which included a discussion about how our hardware partners want to improve accessibility, 190 code changes that were accessibility related and a new accessibility inspector application! There was also notes around the Appium CI/CD test suite and Selenium driver test suite to help with ensure accessibility in our as well as Project Spiel a new text to speech engine for the Free Desktop plus turning accessibility into a permanent goal for KDE.

Nate Graham wrapped up his goals around automation and systematisation. These were about being lazier in a good way, automating the boring trivial things we spend time doing all the time. Creating policies to reduce the debate on issues with opinions impacting what we do, instead of policy. Working as teams instead of alone and documenting how we do things instead of keeping tribal knowledge locked away in our brains.

I wasn't able to attend much of Cornelius Schumacher's KDE Eco goal so I didn't get any notes on that but I do love that KDE cares for the environment and this should be an ongoing goal to make sure our software (and hardware partners) are acting responsibly to ensure a brighter future for the next generations.

Report of the Board

The KDE board assembled in person to give us a run-down of 2023 including all their favourite things that happened like paying members going from 53 to 719, GitHub sponsors up to 132 from 67, and 170 nonmember recurring donations up from 130 on Donorbox! On top of that, the best fundraising campaign ever in December 2023. A monumental task was also completed with the release of Plasma 6 alongside Frameworks and Gear at the same time! The KDE Eco grant was extended, they hired new staff as part of the Make a Living goal, including someone to manage the goals. The new financial situation improved vastly due to a successful Donorbox rollout and fundraising campaign.

In looking to the future the board are encouraging more community members to get on board with the KDE Goals, with the improved finance situation they are hoping to leverage that to continue improving KDE's offerings. Conferences and in-person sprints are now viable post-apocalypse! Ask for funding/organisation from the board if you want to organise/attend one and represent KDE! They are also aiming to move beyond the Make a Living effort and leverage current staff for further work without losing sight of their goals and improve management of staff, contracts and keeping staff on. They're also hoping to expand our app store presence on Google Play, Windows Store and Flathub to get more apps on and investigate possible revenue sources from this.

Adapt or Die: How new Linux packaging approaches affect wider KDE

David Edmundson gave an awesome talk about Linux packaging and where we are headed. Flatpaks! Oh, and I guess Snaps and Appimages and that new one from Deepin… But his talk was generally focussed on how KDE as a community will need to face the challenges of containerised applications since immutable distros are appearing all the time now. In this well researched discussion, he raised several case studies that he has identified as problem points for progress. This was one of my favourite talks, as I am a big proponent of Flatpak as the future of application distribution and plan on working with David to that end.

Looking Back: What's Next

Wait what? What does that even mean? Nicolas Fella decided to share with us his run-down on how the porting from Qt5 to Qt6 went as a whole. From the timeline stretching way back to 2019 to the KDE Megarelease of 2024 including how each step was planned out and then managed into a reality. He also gave us a run-down of the good and the bad from his viewpoint. The good included lots of great new features and loads of pre-release testing. The bad included bugs (but you can never get rid of all of these), controversial decisions and broken distros as of release. He also noted a lack of documentation for third party users of KDE frameworks and some things that got left on the cutting room floor due to a lack of time to get them in. Those have been marked TODO KF7 😂

An Operating System of Our Own

Harald Sitter gave us a run-down of his new Operating System KDE Linux (previously - and my favourite name - Project Banana). This is a new image based distro that uses BTRFS and images of the OS, with easy switching between them. This will be designed for anyone to use, from KDE developers to users and hardware vendors! It will bring apps from Flatpak (my favourite) and Snap to keep the OS and applications separate. I've been watching this for a little while before Akademy so I was happy to see it announced, and it has attracted many people onboard and has accelerated the development of it immensely! Come join us @ #kde-linux:kde.org on Matrix!

A look on the Bright Side of Life

Harald gave us a quick lightning talk about remaining calm and enjoying what we do. Sometimes things are annoying or frustrating but sometimes we need to step back, look at all the awesome things we make and the amazing people we do that with. If in doubt, ask for help or a rubber duck and come back to fight another day.

Sunday Talks!

Sadly I didn't take a lot of notes on Sunday but I attended a few talks.

• Openwashing - How do we handle (and enforce?) OSS policies in products? by Markus Feilner, Holger Dyroff, Richard Heigl, Leonhard Kugler and Cornelius Schumacher. A discussion on companies using the title and reputation of open source without actually being open or contributing anything to the community.

• Group Photo - My first time in a KDE related photo!

• Contributing is more than just code by Kai Uwe Broulik was a really important talk for me as I can't code. It's just not how my brain works, but the topic of his talk resonated with me so much. KDE has lots of code, frameworks, apps, libraries and that requires a lot of code. But there is SO much more work to be done around that code, translations, quality assurance, bug triaging, documentation just to name a tiny few. If you're interested in contributing to KDE, there are LOTS of things you can help with!

• Financial support for working on KDE Jos van den Oever gave a great talk about how you as a KDE contributor can apply for funding. It was mostly focussed around NLnet who had a representative there to encourage us to apply for funding and explain the application and approvals processes. They also stuck around for the next few days to help anyone who wanted to apply to submit their application!

Daily driving Plasma Mobile and what's still lacking

Another talk that really hits home for me was by Bart Ribbers on Plasma Mobile. We've got amazing stories for our desktop offering, but the mobile space is a huge part of most people's daily lives. So many people don't own a computer any more, and they're living their digital life through a mobile phone. This talk gave insight into Bart's daily life with his Plasma Mobile enabled phone and where we need to narrow our focus to improve the experience.

BoFs & Daytrip

Over the following days I attended many BoFs:

• Opt Green: Website Bloat and Green Web which we discussed how our website content affects the environment, from intensive JavaScript, oversized or large images increasing CPU usage and bandwidth to the core of the web itself and what Data Centres and traffic hubs use for their electricity, is it renewable or fuelled by dirty fossil fuels

• Opt Green / KDE Eco which was all about KDE Eco's certification of Okular, their involvement in defining the Blue Angel specification, getting more KDE apps certified and how KDE was recognised as an expert in sustainability in the German parliament!

• KDE Goals - We care about your Input where discussions happened around how we improve input methods for those who use alternate languages and alphabets to game controllers and digital input tablets and devices.

• KDE's release schedules was all about starting discussions about when and how we release software, including how we can better cooperate with downstream distros who are kindly distributing our software

• Plasma Discover by Aleix gave us insight into the recent changes to performance by Harald and himself, and just a great general discussion around Plasma's current state and what is needed for the future of software stores. KDE Goals - Streamlined Application Development Experience was a rather interesting chat about how we currently develop apps and many discussions about how we improve that process, introduce new blood to the community and make it seriously easy to start a new KDE application.

Food!

This worried me in the lead up and on my way to Germany, as I had earlier this year decided to go Vegetarian. However, I was delightfully surprised and the quality and variety of food available, with the food organised by Akademy team being inclusive of my requirements and tasty! The food at University cafeteria was also amazing to my surprise and I learned that they had won awards!

I also thankfully found some students who sold me a crate of Cola for 10 Euros. I grabbed one and gave the rest to the Akademy help desk for them to give out to attendees for a 1 Euro donation ;)

Outro

• What an amazing event, thank yous in no particular order go to Nate Graham, the KDE e.V for sponsoring my travel, the Akademy team and everyone I met at Akademy for making it an awesome experience especially for someone who hasn't been to a conference before, to all of the KDE community for making awesome software and the Akademy and KDE sponsors who make these events possible!

29 Oct 2024 12:00am GMT

Fractional scaling is hard. Anyone that had the misfortune of working on it knows that… so it won't surprise a lot of people that it's not all figured out yet! Today I'll talk about the fractional scaling problems with KWin's server side decorations, and why we need to do an API break to fix it.

What's the problem?

This is the simplest part. Many decorations have elements that need to be pixel perfect, like outlines that are only a single pixel wide. When they're not perfectly scaled, or positioned wrongly, that's sometimes quite visible and annoying:

What causes these issues?

The source of all evil with fractional scaling is also the cause of most issues here: Integer logical coordinates.

Logical coordinates are a way to represent the size of something on the screen in a mostly display-independent way and are quite useful for the size and position of things like windows or the cursor. They're calculated in a really simple way:

coordinate_logical = coordinate_pixels / scale

With just that equation, there are no problems just yet - you can just multiply the logical coordinate with the display scale, and you get back the original coordinate in pixels. When you round that logical coordinate, and do some calculations with it, things get weird though… let's look at the concrete example of a window at scale 1.25, and with a 1 pixel wide outline:

As you might've guessed, KWin's decoration plugin API is using integer logical coordinates, and this mismatch between the window size vs. the size of its components causes most of the problems. Just doing a straight forward int -> float conversion isn't enough to fix this though, a few more changes are needed.

Changes in KWin

KWin will provide decorations with the fractional logical size of windows, provide them with the scale factor they should render for, and use the decoration's fractional border sizes to position the window and decoration pieces properly in the scene.

Changes in Decorations

Because of the API break, decorations using the C++ API need to be updated to the new KDecoration3 API, or they will not be loaded. A minimalistic port would only need to round all the values, but there will of course still be fractional scaling issues with that.

Assuming you want to make the decoration work properly with fractional scaling, you also need to use the provided scale factor to calculate border sizes, and when painting things with QPainter, you need to take care to snap all geometries to the pixel grid, or anti-aliasing may turn single-pixel lines into a blurry mess.

Note that this work isn't completed yet, and some additional API changes may happen while we're breaking the API already. A porting guide with all the changes will be provided before the release of Plasma 6.3.

As Aurorae decorations are just svg files, they are not affected by this API break and will continue to work like before without any changes.

If you have any questions about this change, or about how to port a decoration over to the new API, please reach out to us at #kwin:kde.org on matrix!

28 Oct 2024 11:00pm GMT

One of the quickest ways to determine whether particular application runs using Xwayland is to resize one of its windows and see how it behaves, for example

While it can be handy for the debugging purposes, overall, it makes the Plasma Wayland session look less polished. So, one of the goals for 6.3 was to fix this visual glitch.

This article will provide some background behind what caused the glitch and how we addressed it. Just in case, here's the same application, which was shown in a screen cast above, but with the corresponding resizing fixes in:

X11 frame synchronization protocol(s)

On X11, all window changes typically take place immediately, including resizing. This can lead to some issues. For example, if a window is resized, it can take a while until the application repaints the window with the new size. What if the compositing manager decides to compose the screen in meanwhile? You're likely going to see some sort of visual glitches, e.g. the window contents getting cropped or seeing parts of the window that have not been repainted yet.

In order to address this issue, there exists an X11 protocol to synchronize window repaints during interactive resize. An application/client wishing to participate in this protocol needs to list _NET_WM_SYNC_REQUEST in the WM_PROTOCOLS property of the client window and also set the XID of the XSync counter in the _NET_WM_SYNC_REQUEST_COUNTER property. When the WM wants to resize the window, the following will happen:

1. The window manager sends a _NET_WM_SYNC_REQUEST client message containing a serial that the client will need to put in the XSync counter after processing a ConfigureNotify event that will be generated after the window is resized. The compositing manager and the window manager will block window updates until the XSync request acknowledgement is received;
2. The WM resizes the client window, for example by calling the xcb_configure_window() function;
3. The client would then repaint the window with the new size and update the XSync counter with the serial that it had received in step 1;
4. The window manager and the compositing manager unblock window updates after receiving receiving the XSync request acknowledgement. For example, now, the window can be repainted by the compositing manager and there shouldn't be glitches as long as the client behaves well.

Note that the window manager and the compositing manager are often the same. For example, both KWin and Mutter are compositing managers and window managers.

The frame synchronization protocol described above is called basic frame synchronization protocol. There is also an extended frame synchronization protocol, but it is not standardized and it is implemented only by a few compositing managers.

_NET_WM_SYNC_REQUEST and Xwayland

KWin supports the basic frame synchronization protocol, so there should be no visual glitches when resizing X11 windows in the Plasma Wayland session, right? At quick glance, yes, but we forget about the most important detail: Wayland compositors don't use XCompositeNameWindowPixmap() or xcb_composite_name_window_pixmap() to grab the contents of X11 windows, instead they rely on Xwayland attaching graphics buffers to wl_surface objects, so there is no strict order between the Wayland compositor receiving an XSync request acknowledgement and graphics buffers for the new window size.

In order to help better understand the issue, let's consider a concrete example. Assume that a window with geometry 0,0 100x100 is being resized by dragging its left edge. If the left edge is dragged 10px to the right, the following will happen:

1. A _NET_WM_SYNC_REQUEST client message will be sent to the client containing the XSync counter serial that must be set after processing the ConfigureNotify event that will be generated after the Wayland compositor calls xcb_configure_window() with the new window size;
2. The Wayland compositor calls xcb_configure_window() to actually resize the window;
3. The client receives the sync request client message and the ConfigureNotify event, repaints the window, and acknowledges the sync request;
4. The Wayland compositor receives the sync request acknowledgement and updates the window position to 10,0.

But here is the problem, when the window position is updated to 10,0, it's not guaranteed that the wl_surface associated with the X11 window has a buffer with the new window size, i.e. 90x100. It can take a while until Xwayland commits a graphics buffer with the right size. In meanwhile, the compositor could compose the next frame with the new window position, i.e. 10,0, but old surface size, i.e. 100x100. It would look as if the right window edge sticks out of the window decoration. After Xwayland attaches a buffer with the right size, the right window edge will correct itself.

So, ideally, the Wayland compositor should update the window position after receiving the XSync request acknowledgement and Xwayland attaching a new graphics buffer to the wl_surface.

With that in mind, the frame synchronization procedure looks as follows:

1. The compositor blocks wl_surface commits by setting the _XWAYLAND_ALLOW_COMMITS property to 0 for the toplevel X11 window. This is needed to ensure the consistent order between XSync request acknowledgements and wl_surface commits. As long as the _XWAYLAND_ALLOW_COMMITS property is set to 0, Xwayland will not attempt to commit the wayland surface, for example attach a new graphics buffer after the client repaints the window;
2. The compositor sends a _NET_WM_SYNC_REQUEST client message as before;
3. The compositor resizes the client window as before;
4. The client repaints the window and acknowledges the XSync request as before;
5. After receiving the XSync acknowledgement, the compositor unblocks surface commits by setting the _XWAYLAND_ALLOW_COMMITS property to 1. Note that the window updates are still blocked, i.e. the window position is not updated yet;
6. After Xwayland commits the wl_surface with a new graphics buffer, the window updates are unblocked, e.g. the window position is updated.

The frame synchronization process looks more involved with Xwayland, but it is still manageable.

_NET_WM_SYNC_REQUEST support in applications

Most applications that use GTK and Qt support _NET_WM_SYNC_REQUEST, but there are applications that don't participate in the frame synchronization protocol. If you use one of those apps, you will observe visual glitches during interactive resize.

Closing words

Frame synchronization is a difficult problem, and requires some very intricate code both on the compositor and the client side. But with the changes that we've made, I'm proud to say that KWin is one of the few compositors that properly handles frame synchronization for X11 windows on Wayland.

I would also like to express many thanks to the Xwayland developers (Michel Dänzer and Olivier Fourdan) for helping and assisting us with fixing the glitch.

28 Oct 2024 4:59pm GMT