Kirigami Addons 1.3.0 is out. Kirigami Addons is a collection of components to enhance your Kirigami/QML application. This release contains many change related to the settings module.

ConfigurationView

The current way to create a settings page in your application is to use CategorizedSettings with some SettingAction for each setting page. This was based on Kirigami.PageRow which was then either pushed on a layer on mobile or to a seperate page on desktop. This turned out to be quite unreliable in practice as Kirigami.PageRow is a visual element.

The new ConfigurationView is based on a plain non-visual QtObject with for the moment two backends:

• One for mobile which looks similar to the Plasma Settings application of Plasma Mobile.
• One for desktop which looks similar to the System Settings application of Plasma Desktop.

The API is almost the same as the previous CategorizedSettings which made porting quite easy. Here is for example a button that open the settings.

import QtQuick.Controls as Controls
import org.kde.kirigamiaddons.settings as KirigamiSettings

Controls.Button {
 id: button

 KirigamiSettings.ConfigurationView {
 id: configuration

 window: button.Controls.ApplicationWindow.window as Kirigami.ApplicationWindow

 modules: [
 KirigamiSettings.ConfigurationModule {
 moduleId: "appearance"
 text: i18nc("@action:button", "Appearance")
 icon.name: "preferences-desktop-theme-global"
 page: () => Qt.createComponent("org.kde.tokodon", "AppearancePage")
 },
 ...
 KirigamiSettings.ConfigurationModule {
 moduleId: "about"
 text: i18nc("@action:button", "About Tokodon")
 icon.name: "help-about"
 page: () => Qt.createComponent("org.kde.kirigamiaddons.formcard", "AboutPage")
 category: i18nc("@title:group", "About")
 }
 ]
 }

 icon.name: 'settings-configure-symbolic'
 text: i18nc("@action:button", "Settings")

 onClicked: configuration.open()
}

With this change, both CategorizedSettings and SettingAction are now deprecated.

SpellcheckingConfigurationModule

With ConfigurationView each page is a ConfigurationModule and Kirigami Addons provides a ConfigurationModule for the spellchecking configuration of your application. This will allow to reduce code duplication between NeoChat, Tokodon, Marknote and more applications which uses Sonnet.

KirigamiSettings.ConfigurationView {
 modules: [
 KirigamiSettings.SpellcheckingConfigurationView {}
 ]
}

FormCard

FormCard design was slighly updated and now uses shadows as you might have already noticed from the previous screenshots.

SearchPopupField

Another component which is getting deprecated in SearchPopupField, there is now a replacement for that in Kirigami with the same behavior and I added an example how to port away to Kirigami.SearchDialog and I also ported all the know usage already.

Maintainance work

Aside from this major changes, there is ongoing maintaince works. This includes:

• Removing the accidental QtWidgets on Android caused by QtLabs.ColorDialog (me: Carl Schwan)
• Ensure all translated strings are loaded from the correct translation domain (me: Carl Schwan)
• The license dialog in the AboutPage is now opened in the correct window (Jack Hill)
• Fix the focus in the FormComboBoxDelegate (Joshua Goins)
• Fix the capitalization in the AboutPage (Joshua Goins)
• Increase the padding in FormCardDialog to match the other FormCard components

Packager Section

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

Hash-o-Matic 1.0.1 is out! Hash-o-Matic is a tool to compare and generate checksum for your files to verify the authenticity of them. It also verify files via their use PGP signatures.

This new release of Hash-o-Matic provides updated translations and some small visual changes. In the background, the application was ported to the new QML type registration, we now support building Hash-o-Matic on Haiku and we now require released version of KDE Frameworks instead of pre-released version.

Packager Section

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

Tellico 3.5.5 is available, with a few important fixes.

Improvements and Bug Fixes

• Fixed the XSLT file loading to work correctly with libxml2 >= 2.13 (Bug 488707).
• Fixed bug for showing entries with large content (Bug 487079).
• Improved the SRU fetcher to allow user-defined search indices (Bug 488931).

Kommit 1.6.0 is a feature and bugfix release of our Git repo app which now builds with Q 5 or 6.

Improvements:

• build without kdbusaddons on windows
• Add flatpak support
• Fix show date (using QLocale for it)
• Fix mem leak
• Reactivate open file in external apps in qt6
• Add zoom support in Report Chart Widget
• Replace a QTableWidget by QTreeWidget in report page
• Fix crash when we didn't open git repository
• Fix load style/icon on windows (KF >= 6.3)
• Implement a gravatar cache
• Fix i18n

URL: https://download.kde.org/stable/kommit
Source: kommit-1.6.0.tar.xz
SHA256: 4091126316ab0cd2d4a131facd3cd8fc8c659f348103b852db8b6d1fd4f164e2
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Esk-Riddell jr@jriddell.org
https://jriddell.org/esk-riddell.gpg

KWin had a very long standing bug report about bad performance of the Wayland session on older Intel integrated graphics. There have been many investigations into what’s causing this, with a lot of more specific performance issues being found and fixed, but none of them managed to fully fix the issue… until now.

The source of the problem

Understanding the issue requires some minimal understanding about how displays work. My earlier post about gaming on Wayland goes into more depth about them and the different presentation modes, but the TL;DR is that most displays today require frames to be sent to it in fixed intervals if you want them to be shown without tearing artifacts.

With the vast majority of displays, that interval is 16.67ms. In order to show everything as smooth as possible, the compositor thus has to render a new frame every 16.67ms as well; it must not miss a single deadline or the user will see stutter as some frames are shown twice and others are skipped.

This problem is not unique to Intel of course, when the deadline is missed, that causes the same stutter on every system. It’s just an often reported issue on old Intel processors because they’re used a lot, because both CPUs and GPUs in them are pretty slow, and laptop manufacturers too often paired them with high resolution screens, requiring the GPU to render for a long time each frame.

How KWin deals with this deadline

In the past, KWin would just start compositing immediately once the last frame was presented, to have as much time as possible for rendering; this worked pretty well but meant that it almost always rendered too early. On desktop GPUs, compositing can take as little as a few hundred microseconds; if we start compositing 16ms before the deadline, that means we’re also unnecessarily increasing latency by roughly 16ms, which makes the system feel less responsive.

For KWin 5.21, Vlad Zahorodnii implemented a scheduling mechanism to do this better: Instead of assuming we always need the whole frame for rendering, KWin measures how long rendering takes and could start compositing closer to the deadline, which reduced latency. However, this strategy could still not get very close to the deadline by default, because it only measured how long rendering took on the CPU, but not how long it took on the GPU.

For KWin 6.0, I implemented the missing part, recording GPU render times. This meant that we could reduce latency more, without causing stutter… Or at least that was the idea. It turns out, render times are very volatile at times; KWin’s rendering can be delayed by other apps using the CPU and GPU, by the hardware changing power management states, by additional windows opening, by KWin effects starting to render something heavy, by input events taking CPU time, and so on.

As a result, taking a simple average of recent render times wasn’t enough, and even taking the maximum wasn’t good enough to prevent all the noticeable stutter. Instead, KWin now analyzes past render times for how volatile they are, and starts compositing much earlier if they’re volatile, and only moves closer to the deadline when render times are stable and predictable. This will likely be tweaked a few more times as I can collect more render time data from different PCs and optimize that algorithm with it, but so far it works pretty well, and gets us the best of both worlds: High latency when necessary to prevent stutter, and low latency when possible.

So, with these old Intel processors, KWin should now detect that rendering takes long and render times are not very stable, and start rendering as early as possible, and that should fix everything, right? Unfortunately, that’s not the whole story.

Old Intel processors are just too damn slow!

On these old processors, especially when paired with a 4k screen, rendering doesn’t just take long, it often takes too long for a frame to be completed after 16.67ms! All the previous improvements were useful, but can’t make the hardware faster.

In the very beginning of the post I hinted that this is a Wayland only problem though, so what’s going on on Xorg? kwin_x11 has a trick that makes this problem less severe: On the start of each refresh cycle, it starts rendering a frame, even if the last frame isn’t done rendering yet. This is called “triple buffering”¹ because it uses up to three buffers at the same time (two for rendering, one for displaying) and it has two big benefits:

• while the GPU is still working on the last frame, the CPU can already prepare rendering commands for next one. As long as both CPU and GPU individually take less than 16.67ms, you can still get one image rendered for each frame the display can present
• because more frames are being rendered, the driver may increase CPU and GPU clock speeds, which makes rendering faster and might allow for hitting the full refresh rate

However, it also has some caveats:

• it increases latency in general, as rendering is started earlier than necessary
• when rendering takes more than one refresh duration, latency is increased by a whole refresh duration - even if it would only need a single millisecond more for rendering
• to avoid increasing latency for dedicated GPUs, it’s only active on Intel GPUs and never used elsewhere
• it’s active even on Intel GPUs that have good enough performance to not need it
• when the driver increases GPU clocks because of triple buffering, that may be enough for rendering to be fast enough to not need triple buffering anymore… which means the GPU clocks will reduce again, and frames will be dropped until triple buffering is active again, and that repeats in a cycle. This can, in some situations (like video playback), be more noticeable than a reduced but constant refresh rate.

The goal then was to implement a form of triple buffering that would come with the same benefits, without also having the same shortcomings. First, a few things needed to be patched up to allow for triple buffering to work.

Fixing prerequisites

The DRM/KMS kernel API currently only allows a single frame to be queued for presentation at a time. When you submit a frame to the kernel, you have to wait until it’s done rendering and shown on the screen, before you’re allowed to commit the next frame - but for triple buffering we need to queue two frames. Luckily I had already implemented a queue for other functionality with a drm commit thread (check out my previous post about cursor updates for details), so this one was mostly taken care of already and only needed minor changes.

The queue wasn’t good enough yet though. If KWin’s render time prediction is too pessimistic and it starts rendering much earlier than necessary, it could end up rendering two frames that are meant for consecutive refresh cycles, and complete rendering both during the same refresh cycle… which means that GPU power is wasted. Worse, as the refresh rate of apps is coupled to KWin’s, apps would try to render twice as fast too! To fix that, frames are now simply delayed until the time they’re intended to be displayed.

In order to figure out how long compositing takes on the GPU, KWin uses OpenGL query objects. These are quite useful, but they have three issues for triple buffering:

• query objects only hold a single result. If you start two queries, the last one gets dropped
• if you query a timestamp for commands that haven’t finished executing yet, OpenGL will do a blocking wait until that’s done
• they’re bound to an OpenGL context, which especially complicates things with multiple GPUs

To avoid the last problem, I did a bunch of OpenGL refactors that removed unnecessary global state from OpenGL code, and encapsulated what was left in OpenGL context objects. Render time queries in KWin now store a reference to the OpenGL context object they were created with and handle the context switching for fetching the result themselves, so code using them doesn’t have to care a lot about OpenGL anymore. With that done, the other two issues were fixed by simply creating a new query for each frame, which gets queried after the frame is done rendering, and never gets reused.

Actually implementing triple buffering

After these prerequisites were taken care of, I extended the existing infrastructure for frame tracking, OutputFrame objects, to encapsulate more properties of presentation requests and handle render time tracking as well as presentation feedback directly. With all information and feedback for each frame being tracked in a single object, a lot of presentation logic was simplified and allowing multiple pending frames ended up being a relatively simple change in the drm backend.

To make use of that capability, I extended the render scheduling logic to allow render times of up to two frames. It computes a target presentation timestamp by calculating how many refresh cycles have gone by since the last presented frame and how many refresh cycles rendering will take. If there’s already a frame pending, it just ensures that the refresh cycle after that is targeted instead of the same one… and that’s almost it.

Remember how I wrote that displays refresh in a fixed time interval? Well, it’s not that simple after all. Timings can fluctuate quite a bit, and that could make KWin sometimes schedule two frames for the same refresh cycle, just for the older one to get dropped again and be a complete waste of energy and even cause stutter. As a fix, when the last frame completes and provides a more accurate timestamp about when the next refresh cycle begins, KWin now reschedules rendering to match it.

This is the state of things in the 6.1.0 release; since then issues on a few systems were reported and more adjustments may still be added - in particular, some sort of hysteresis to not make KWin switch between double- and triple buffering too often.

The result

With all those changes implemented in Plasma 6.1, triple buffering on Wayland

• is only active if KWin predicts rendering to take longer than a refresh cycle
• doesn’t add more latency than necessary even while triple buffering is active, at least as long as render time prediction is decent
• works independently of what GPU you have

In practice, on my desktop PC with a dedicated GPU, triple buffering is effectively never active, and latency is the same as before. On my AMD laptop it’s usually off as well, only kicking in once in a while… But on some older Intel laptops with high resolution screens, it’s always active and I’ve been told it’s like having a brand new laptop - KWin goes from doing stuttery 30-40fps to a solid 60fps.

It’s not just old or slow processors that benefit though, I also tested this on a laptop with an integrated Intel and a dedicated NVidia GPU. With an external display connected to the NVidia GPU, due to some issues in the NVidia driver, multi gpu copies are quite slow, and without triple buffering, the external monitor was limited to 60fps. Triple buffering can’t do magic, but KWin now at least reaches around 100-120fps on that setup, which is likely the best that can be done until the driver issue is resolved and feels a lot smoother already.

The first month of the coding period of GSoC has already passed! Since the last update, I added Python support for the remaining classes of KWidgetsAddons. It was only recently when I discovered that apart from the C++ classes, the libraries also have namespaces which I didn’t even know about. So it turned out that it wasn’t actually completed. But anyway, there were only a few so that is now done. I also added support to automatically build a Python wheel for the bindings.

Last week I improved some Python demos and added bindings for KCoreAddons. That was quicker than I expected, so I might end up adding support for 5-7 more libraries that it was initially planned for. Here’s a list of the libraries that I plan to add during the rest of the summer:

• KI18n
• KGuiAddons
• KNotifications
• KUnitConversion
• KXMLGui

Let’s go for my web review for the week 2024-25.

Proton is transitioning towards a non-profit structure

Tags: tech, internet, ethics, privacy

Very interesting move. I wish them well!

https://proton.me/blog/proton-non-profit-foundation

Licensing teams will target unwitting Oracle Java users • The Register

Tags: tech, java

Oracle doing Oracle things I guess… The surprising bit to me is the fact that so many people still seem to use Java SE while there are other excellent alternatives.

https://www.theregister.com/2024/06/20/oracle_java_licence_teams/

Microsoft Refused to Fix Flaw Years Before SolarWinds Hack — ProPublica

Tags: tech, microsoft, security

A deep dive into the events which led to the SolarWinds breaches. The responsibility from Microsoft as an organization is staggering. Their handling of security matters massively failed once more. I don’t get how governmental agencies or other companies can still turn to Microsoft with sensitive data.

https://www.propublica.org/article/microsoft-solarwinds-golden-saml-data-breach-russian-hackers

Microsoft delays Recall again, won’t debut it with new Copilot+ PCs after all | Ars Technica

Tags: tech, microsoft, security

Very unsurprising, the harm is probably done though. They’ll have to work hard for their reputation to recover (even though it was probably low already).

https://arstechnica.com/gadgets/2024/06/microsoft-delays-data-scraping-recall-feature-again-commits-to-public-beta-test/

Edward Snowden Says OpenAI Just Performed a “Calculated Betrayal of the Rights of Every Person on Earth”

Tags: tech, gpt, surveillance

It was already hard to trust this company, but now… that clearly gives an idea of the kind of monetization channels they’re contemplating.

https://futurism.com/the-byte/snowden-openai-calculated-betrayal

GitHub Copilot Chat: From Prompt Injection to Data Exfiltration · Embrace The Red

Tags: tech, ai, machine-learning, gpt, copilot, security, privacy

The creative ways to exfiltrate data from chat systems built with LLMs…

https://embracethered.com/blog/posts/2024/github-copilot-chat-prompt-injection-data-exfiltration/

I Will Fucking Piledrive You If You Mention AI Again — Ludicity

Tags: tech, ai, machine-learning, gpt, data-science, criticism, funny

OK, this is a rant about the state of the market and people drinking kool-aid. A bit long but I found it funny and well deserved at times.

https://ludic.mataroa.blog/blog/i-will-fucking-piledrive-you-if-you-mention-ai-again/

Block AI training on a web site

Tags: tech, ai, machine-learning, gpt, self-hosting, criticism

Since there are ways to offset the plagiarism a bit, let’s do it. Obviously it’s not perfect but that’s a start.

https://blog.zgp.org/block-ai-training-on-a-web-site/

How free software hijacked Philip Hazel’s life

Tags: tech, foss, maintenance, life, history

Very interesting piece… shows how someone can end up maintaining something essential for decades. This is a lesson for us all.

https://lwn.net/SubscriberLink/978463/be23210c163a2107/

DDoS attacks can threaten the independent Internet

Tags: tech, networking, security, self-hosting, internet

This is indeed a real concern… with no propre solution in sight.

https://www.macchaffee.com/blog/2024/ddos-attacks/

We don’t know what’s happening on our networks

Tags: tech, networking, security

On the peculiarities of running a network for a university… this is an interesting way to frame it as basically being an ISP with benefits.

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OurNetworkTrafficIsUnknown

Why you shouldn’t parse the output of ls - Greg’s Wiki

Tags: tech, shell, scripting

This is indeed an easy mistake to do. It’s better be avoided.

https://mywiki.wooledge.org/ParsingLs

Versioning FreeCAD files with git - lambda.cx blog

Tags: tech, tools, git, cad

Interesting trick for a zip based format containing mostly text.

https://blog.lambda.cx/posts/freecad-and-git/

Joining Strings in Python: A “Huh” Moment - Veronica Writes

Tags: tech, python, memory, performance

Interesting dive into how join() and generator behave in CPython.

https://berglyd.net/blog/2024/06/joining-strings-in-python/

Understanding a Python closure oddity

Tags: tech, programming, python

That’s what happens where references are half hidden in a language. You think each closure get a different copy but in fact they all refer to the same object.

https://utcc.utoronto.ca/~cks/space/blog/python/UnderstandingClosureOddity

Regular JSON – Neil Madden

Tags: tech, json, security

JSON, its grammar and the security implications. The approach of looking at a restricted subset is interesting.

https://neilmadden.blog/2023/05/31/regular-json/

Demystifying Rust’s ? Operator

Tags: tech, programming, rust

Ever wondered how this operator is implemented in Rust? It’s not that complicated.

https://blog.sulami.xyz/posts/demystifying-rusts-questionmark-operator/

I’ve Stopped Using Box Plots. Should You? | Nightingale

Tags: tech, data-visualization

Why box plots are hard to grasp and probably badly designed. There are good alternatives out there though.

https://nightingaledvs.com/ive-stopped-using-box-plots-should-you/

When To Write a Simulator

Tags: tech, complexity, probability, simulation

Some problems are indeed tackled faster by having a simulation allowing to explore potential solutions. It’s tempting to go very formal and theoretical but it’d require more effort and be more error prone.

https://sirupsen.com/napkin/problem-16-simulation

Major version numbers may not be sacred, but backwards compatibility is

Tags: tech, library, api, maintenance

Good musing about major version numbers and backward compatibility. It is indeed important to communicate breaking changes properly and to not have those too often.

https://blog.cessen.com/post/2022_07_09_major_version_numbers_may_not_be_sacred

What’s hidden behind “just implementation details” | nicole@web

Tags: tech, software, programming, work, complexity

It might not look like a lot from the outside, but “just implementation details” in fact hides quite some work and complexity.

https://ntietz.com/blog/whats-behind-just-implementation/

A Note on Essential Complexity

Tags: tech, software, organization, complexity

Very nice piece about the various types of complexities we encounter in our trade, and what we can or should do about it.

https://olano.dev/blog/a-note-on-essential-complexity

Simple sabotage for software · Erik Bernhardsson

Tags: tech, software, management

This is a funny pretense, and yet… If any of this remind you of a real context, this would be paper cuts. Have enough of those and indeed the organization might grind to a halt.

https://erikbern.com/2023/12/13/simple-sabotage-for-software.html

Never, Sometimes, Always - lukeplant.me.uk

Tags: tech, requirements, software, product-management

This is indeed a good way to classify events probability in requirements. It definitely impacts how you handle them in software.

https://lukeplant.me.uk/blog/posts/never-sometimes-always/

Start Presentations on the Second Slide - by Kent Beck

Tags: tech, communication, talk

Nice trick, definitely should use it more often.

https://tidyfirst.substack.com/p/start-presentations-on-the-second

On Ultra-Processed Content - Cal Newport

Tags: tech, information, social-media, criticism

Indeed the analogy from “ultra-processed food” is an interesting one in the information context.

https://calnewport.com/on-ultra-processed-content/

Bye for now!

The first maintenance release of the 24.05 series is out fixing issues in the spacer tool, effects and compositions, subtitle management and project settings to name a few. We addressed recently introduced crashes and freezes, including fixing the undo/redo track insertion and multiple track insertion issues. This version also improves AppImage packaging and enables notarization for macOS.