Long Covid. If you are at all conversant with C20 twenties and thirties detective novels, you’ll know all about the invalids, the incapabables, the chronically ill. That was the flu. Though it never is the protagonist who is suffereing, it’s always someone else.

Well, this time it’s me. The protagonist of my own life.

I got covid when I got jabbed, early 2022. In the vaccination centre. Not because of the vaccine, but because, for some reason, everyone was expected to sit down, in a perspex cubicle for fifteen minutes, unmasked.

Of course, as you know, the covid virus remains infectuous for six hours and airborne, no droplets needed, in any area an infected person has been breathing for about ten minutes.

And no vaccine is immediately effective.

These were incubation incubators.

So I got sick. Really sick. For two weeks I had a horrible fever and was completely bed-ridden.

The aftermath is worse though.

I noticed my cognition was going down: I was (and am) getting dumber. Concentration powers going down. Getting pukey, and after that, shitty, regularly. Heart rates getting up into realms no blood pressure measurement machine could manage to measure. Having to lie down for days.

People wished me well. Wished me to get better soon.

Sorry people, that doesn’t work: this is like M.E., and you don’t get better from that. (In fact, Long Covid might, after all, have provided a pathology that explains M.E.)

Better soon? Bad days are getting increasingly frequent, and while I’l very good on good days, I cannot predict when good days will happen.

There you have it… Puke. Runny shit. Lying down all day in a darkened room. Brain Fog. Every little thing you manage to do is an achievement. Heart palpiations. Doctors telling you you’re malingering. Good days when you’re doubting you are actually sick getting outnumbered by days you cannot even eat, only drink water.

(And don’t ask me about how it’s when your nose if full of the smell of bin liner filled with the intestines of two-weeks dead animals.)

.

..

…

Hey… Masks are the one thing that work.

Happy October and other related holidays! The list of work is a bit smaller, as predicted I was busy this month. However, I have some really exciting work done in PlasmaTube - some of which you may have already seen if you follow me on Mastodon.

I also added a better way to discern bugfixes from features in these posts! It also details which branches and versions the change will appear in. I will be adding this slowly to older posts. I’m also really close to completing a whole year of this blog series, which I started back in January 2023! 🎉 I’ll be detailing more of 2024 plans in December.

Tokodon

[Feature] I added support for viewing server announcements! It doesn’t support emoji reactions yet, because I want to also implement emoji reactions in general (if your server supports it.) [24.02]

[Bugfix] Fixed more cases where media attachments wouldn’t load, if some of the metadata was invalid. [24.02] [23.08]

[Feature] The window geometry and position (if on X11) is now saved and restored. [24.02]

[Feature] A profile’s featured tags are now shown in the filter bar. You can select between them or reset it by tapping on “All”. [24.02]

[Feature] The selected post in a thread is now scrolled to initially, so you don’t have to scroll so much when viewing replies. [24.02]

[Feature] When scrolling to the very end of a timeline, a message is now shown that it’s really the end and you didn’t encounter some kind of bug. [24.02]

[Feature] Tokodon now supports basic notification actions such as viewing the post or the user’s profile. More actions are planned in the future, but this is a good start. [24.02]

[Feature] I cleaned up and merged the offline testing system that was originally pioneered by Rishi Kumar. This doesn’t affect users, but means that Tokodon can be tested more easily. Aka, more stable software! :-) [24.02]

[Bugfix] Add missing PulseAudio, FreeDesktop Secrets and notification permissions for the Tokodon Flatpak. [24.02] [23.08]

NeoChat

[Feature] NeoChat state (such as event cache) will now be stored in it’s own state file, called “neochatstaterc” in ~/.local/share/KDE/neochat. This matches the behavior of other KDE applications, instead of the weirdly named “data” file like before. [24.02]

[Feature] The event cache is now compacted so it’s a little bit smaller, and easier to read. [24.02]

[Feature] The recent emojis are now saved in the state file, instead of the regular config file. Less state in there, woohoo! [24.02]

Kirigami

[Feature] You can now control the isMask property of a Chip. Otherwise, this property is inaccessible, preventing you from changing the icon color. [6.0]

PlasmaTube

I did a ton of work improving PlasmaTube this month. If you haven’t been using PlasmaTube yet, or haven’t tried it in a while… 24.02 in February will be packed with new features and bugfixes!

[Feature] PlasmaTube is now Qt6, complete with the new declarative type registration system. For users, it means that it’s marginally faster and that it’s ready for the February mega-release. [24.02]

[Feature] Different video sources other than Invidious is now supported! The current plan plan is to support Invidious, Piped and PeerTube by 24.02. The feature set of the new video sources are currently limited compared to Invidious, but will be expanded. [24.02]

[Feature] Selecting between video sources is now supported, for example if you have a Invidious instance but also want to watch PeerTube content. [24.02]

[Feature] Along with that, the overall login flow is overhauled to match other Kirigami applications. You can even select from a list of public instances. (Keep in mind that the UI is still a work in progress and will be improved before release.) [24.02]

[Feature] The sidebar is no longer icon only, and matches the UX of other Kirigami applications such as NeoChat, Tokodon and Arianna. There are now several tabs such as “Popular”, “Trending”, “Subscriptions”, “Playlists” and “History”. Some of these are disabled depending on if you’re logged in and if the video source supports them. [24.02]

[Feature] The “Trending” page has been overhauled to use tabs instead of stuffing all of the different types into the page’s actions. [24.02]

[Feature] Added a “Playlists” page! Right now you can only view playlists, but I plan on adding more advanced playlist management soon. [24.02]

[Feature] Added a “History” tab, which of shows you recently watched videos. [24.02]

[Feature] Added a new context menu, shown while long tapping or right-clicking on a video item. You can mark a video as watched or unwatched, add it to a playlist and more. [24.02]

[Feature] Added a picture in picture mode! It’s even possible to control the video using the normal controls in the main window. When closing the PiP window, it will also restore the position in the main player too. [24.02]

[Feature] It’s now possible to use a network proxy in PlasmaTube, but due to FFmpeg limitations you can only set a HTTP proxy unlike other KDE applications which support a SOCKS5 proxy. [24.02]

[Feature] You can now change the default homepage for Invidious sources, which also syncs to the Invidious web frontend and any other clients that support this key. More settings will be available in the future, such as autoplay (which currently does nothing.) [24.02]

[Feature] You can now view comments on a video, which is supported in Invidious, PeerTube and Piped sources. They aren’t very detailed yet, and threading is not yet supported. [24.02]

[Feature] A channel’s avatar, banner and description is now shown on the channel page. Eventually other channel tabs like playlists will be available here too! [24.02]

Merkuro

[Bugfix] Fixed a bug where certain locales would be unable to use the date picker. [24.02] [23.08]

KWallet

[Bugfix] Fixed the “Configure KWallet…” menu item not working. [23.08]

[Feature] Added a visible error message for conditions where KWalletManager could fail and display nothing, like the DBus service failing to activate. [24.02]

KWin

[Bugfix] Fixed the default keybinds for “Switch to Next/Previous Desktop” not being set properly by default, when they probably should. [6.0] [5.27]

Plasma

[Feature] A bunch of small improvements and fixes for the “Show Activity Manager” applet. This is mostly fixing stuff that was broken due to KF6 changes. [6.0]

Kirigami Addons

[Bugfix] Prevent a crash when calculating initials in names that only have parenthesis, such as “(gobble)”. This affects the new Avatar component. [0.12]

See you next month!

During the last years, I’ve been doing a lot of coding and no blogging. That’s a shame because without good announcements, there is no chance for people to know about the code.

All of the projects I’ve been coding on are more or less unfinished which is why I’ve not been too keen on blogging about them. It’s time to get over this inhibition and show the world these rough gems in all their glory.

This blog is just the announcement of more blogs that are about to come. For now, the projects that I’ll be be blogging about are just listed here with a short description and a link to the repository.

I will be fighting the urge to polish the projects more and delay announcing them even further. The plan is to blog about one project per week.

Kwats

RDF graphs contain triples. Prepending the triples from the graph with the IRI of the triples gives quads. The Dutch word kwats sounds like quads but means nonsense.

Kwats is a simple server where triples can be stored and queried. Triples are added in the form of graphs. The graphs are stored as files in git, along with provenance information.

A running server keeps the graphs in memory. Rules about what is allowed in the graphs is written in the form of SHACL.

Subtree of Life

Subtree of Life is a webpage to create phylogenetic trees that show the relationship between the species of your choice. How are cat, dog and bumblebee related? Like this.

The code for this webpage is finished. The user experience, documentation and packaging can be improved.

Xust

Xust was a big COVID project. It is meant to become an XQuery implementation like BaseX and Xidel.

Xust main has 1218 commits and the XQuery functionality is not usable yet. The repository contains Rust crates for an XML DOM, DTD validation, and XML Schema validation.

This is a fun repository to work on because of the large number of tests. The CI shows 75551 tests at the moment that finish in seconds.

Rehorse

Rehorse is a web application for rehearsing music. It started off as way to loop recordings that matches the sheet music. So you can loop easily between, say, measure 10 and 12.

The application has been in production for years but is not very polished. I maintain an instance of it for members of two bands.

Nix flake for KDE software

kde-nix-flake packages KDE software for Nix. Nix is a package manager available for many Linux distributions. It handles packaging, setting up a development environment, testing and deploying.

The file flake.nix contains instructions for running stable and nightly KDE software, setting up a build environment with nix develop, running tests with nix check, using Plasma as a desktop, using the binary cache for quick installation, and running jobs on a CI server.

Keeping this repository up to date with the development speed of KDE has turned out to be a challenge.

Diary

The simply named diary is another unfinished application that has been in production for years. It is a desktop application based on rust-qt-binding-generator that I use to write notes.

It was also meant to keep a calendar and a list of todo’s, but those parts are not finished.

Reworking Recent Files search for Plasma 6

For Plasma 6, lots of KRunner plugins and framework functionalities were improved. I took quite a bit of time to work on the recent files search plugin used by KRunner and Plasmas application launchers like Kickoff. This included performance improvements, usability improvements and technical refactorings.

Let’s start off with the usability improvements: While the runner was named “Recent Files”, it still provided results for directories. In Dolphin on the other hand, “Recent Locations” are a separate location you may access next to “Recent Files”. Luckily, functionality for only querying files already exists in the KActivities-Stats framework :).
The search for files was also improved. Natalie Clarius added some time ago a patch to avoid false positives when the query is part of the file path. For example, when you type for “myfile” and “/home/user/myfiles/test” was a recent file, this file would be returned by the KActivities-Stats framework. With Natalie’s logic, those files would not be shown in KRunner, but still they fill out the limit of recent files we want to query. Of course, one could look for more files in case we discarded too many, but that can cause a performance penalty due to additional SQL queries.
Instead, I have added the ability to filter by the filename in KActivities-Stats. This means false positives are always avoided, and you will for sure get the results you are looking for!

Another useful, but not yet user-facing change is special handling for queries shorter than 3 characters. For those queries, a substring check would cause too many unintended results to be useful. Instead, the filename must start with your given query. Similar to how the Applications-runner handles it. There are plans to make this feature more easily accessible, but for now, it can only be done on the command line using krunner --runner=krunner_recentdocuments.

Screenshot of KRunner in single-plugin mode with the recent files plugin

The final issue that everyone will benefit from being fixed is a memory leak. This means for each letter typed, the runner would allocate a bit more RAM for results from the query. This can add up over time in KRunner and Plasmashell. The KActivities-Stats that were “leaking” also caused CPU overhead, because they were notified about changes to the recent files list – even though they were never used again.
Luckily, you don’t have to worry about that at all from now on :).

Optimizations

Let us start with the small improvements: In my previous posts, I mentioned that constructing a QueryMatch object before being sure that the current item (application or systemsettings module) matches, causes a performance overhead. The same applied to the recent files plugin, because we discarded some files due to the false positive detection mentioned above.
Getting the filename was also optimized/simplified, because instead of using Qt API to get the filename from the URL, we can just use the resource title from KActivities-Stats.
String comparisons were speed up by reusing the results. For example, when checking if the filename contains the query, we can get the resulting index. If that index is 0, the query is contained and the filename also starts with it. Meaning we’d only do one string comparison for each recent file instead of up to 4.

Getting the appropriate icon is also way faster, because previously a method from KIO was used, which gets the file path, checks some extra cases, but usually gets the icon for the determined mime type. Because the extra cases were not relevant when only allowing files, we can directly get the icon for the respective mimetype. Luckily, we don’t even need to determine the mimetype, because the model already contains it.

Reusing previously fetched data

This is the most interesting part and was my original idea to improve performance: In KDE Frameworks 6, each runner lives in its own thread. Meaning, one may access member variables in a thread safe way. The data we want to reuse is the KActivities-Stats ResultsModel. This contains paths and additional metadata of recently used files. The number of files is limited to 20, which is the maximum number of entries is KRunner.
Implementing was straightforward: If one previously typed “firef” and after that “firefox”, the previous model can be reused as long as the limit of 20 did not exceed the previously found results. In addition to reusing the data, it is required to check the filenames again, because a file called “firef.test” should not match a query called “firefox”. Due to the preexisting logic to determine the match relevance, this is minimal additional work.
When measuring the real-world impact, it is important to note that fetching results from KActivities SQLite database is the most expensive part. Accessing the model is relatively cheap. Meaning the longer your queries are and if long as the number of results was not exceeded, your performance gains will be significant!

Profiling of the unoptimized version, loading the correct Icon takes a large porting of CPU cycles Optimized version, CPU cycles are significantly reduced and loading of icons is barely distinguishable from other, minor costs

In benchmarks, one is able to see that the CPU cycles with this patch are roundabout the same among the different measurements, whereas the CPU cycles before this patch correlated with the length of the query. The query was typed in letter by letter, keep in mind that the runner skips queries shorter than 3 characters unless the single runner mode is activated. For benchmarks, I decided against activating this mode, because it is not the normal usecase.

This past weekend I attended the Google Summer of Code Mentor Summit 2023 as part of the KDE delegation.

I have been a mentor for GSOC almost every year since 2005 but this was my first time attending the mentor summit.

There were sessions about the typical things you'd expect: how to get more diverse folks as students, how to make sure we onboard them correctly, sustainability, funding, etc. All in all nothing groundbreaking and sadly no genius solution for the issues we face was given, but to a certain degree it helps to see that most of us have similar problems and it's not that we're doing things particularly wrong, it's just that running a Free Software project is though.

Carl Schwan and me ran a Desktop Linux session together with Jonathan Blandford of GNOME (check his Crosswords game, seems pretty nice) and basically asked folks "How happy are you with the Desktop Linux", you can find the notes about it at https://collaborate.kde.org/s/HKn6BoNCRNezn3K Nothing we don't know about really, Wayland and flatpak/snap are still a bit painful for some folks even if there's a general agreement they are good ideas.

I also organized a little session for all the attendees from Barcelona (it was about 6 of us or so) to sell them talk about Barcelona Free Software

One thing that always pops up in your mind when going to events is "How useful was it for me to attend this" since traveling to California from Europe is not easy, it is not cheap and it means investing quite some time (which in my case included taking vacation from work). 

Honestly, I think it's quite useful and we should attend more similar events. We get to know key people from other projects and we make sure other projects know about us. One of the most funny interactions was me sitting in a table, someone joining and saying "Woah KDE, you guys are super famous, love your work" and literally seconds after another person joining us and saying "Uh, KDE what is that?"

There's not much pictures because Google forbids taking pictures inside their buildings, the few exceptions include the chocolate table, it's quite a large quantity of chocolate we got to try, thanks Robert from Musicbrainz for pushing people to bring it :)

I'd like to thank Google and KDE e.V. for sponsoring my trip to the Summit, please donate at https://kde.org/fundraisers/plasma6member/

The next release for the big three in KDE land (KDE Frameworks, KDE Plasma and KDE Gear) is going to happen at the same time.

This is because we are switching to Qt6[*] and it helps if we can release all the products  at the same time.

If you want to help us with the effort, make sure to donate at https://kde.org/fundraisers/plasma6member/

The agreed schedule is:

8 November 2023: Alpha

KDE Gear 24.01.75 / KDE Plasma 5.80.0 / KDE Frameworks 5.245.0

29 November 2023: Beta 1

KDE Gear 24.01.80 / KDE Plasma 5.90.0 / KDE Frameworks 5.246.0

20 December 2023: Beta 2

KDE Gear 24.01.85 / KDE Plasma 5.91.0 / KDE Frameworks 5.247.0

10 January 2024: Release Candidate 1

KDE Gear 24.01.90 / KDE Plasma 5.92.0 / KDE Frameworks 5.248.0

For KDE Gear that want to ship with Qt6 for this release they need to be switched to Qt6 (and obviously stable) *BEFORE* this date.

31 January 2024: Release Candidate 2

KDE Gear 24.01.95 / KDE Plasma 5.93.0 / KDE Frameworks 5.249.0

21 February 2024: Private Tarball Release

KDE Gear 24.02.0 / KDE Plasma 6.0 / KDE Frameworks 6.0

28 February 2024: Public Release

KDE Gear 24.02.0 / KDE Plasma 6.0 / KDE Frameworks 6.0 

You can see that Alpha is less than 3 weeks away! Interesting times ahead!

[*]  some KDE Gear apps may remain in Qt5 if we have not had time to port them

Do you know isocpp.org's blog? As an open-minded C++ programmer, I am a fond reader and have been inspired multiple times. I always enjoyed the blog posts from Andrey Karpov. He has deep knowledge with static code analysis and is a co-founder of PVS-Studio, a commercial static code analyzer for C++, C#, C, and Java. To advertise new releases of their product, Andrey and his co-workers scan popular open source projects with their tool. They explain the numerous results and showcase by these real-world examples how beneficial static code analysis is even for mature and healthy code bases. I found these posts both entertaining and instructive. If you are not aware of them, you might find them an interesting read: Clang 11, LLVM 15, Qt 6, GCC 13. I find this topic intriguing; nevertheless, for a long time I did not manage to dive deeper into this topic.

I am a satisfied user of Kile, KDE's user-friendly TeX/LaTeX editor. In the span of almost 20 years (Is Kile really that old? When have I gotten this old?), I have typeset dozens of documents with hundreds of pages using Kile. To check Kile's status, I visited its project page. One thing is, that it has not seen a release for a long time. The other thing that caught my eye is the result of cppcheck, visible in every open merge request. Cppcheck is an open-source static code analyzer for C and C++. It tries to find undefined behavior, dangerous code patterns, and bad coding style. GitLab showed a staggering 300+ cppcheck findings for Kile's open merge requests.

Gitab shows for every Kile merge request cppcheck's code quality scan results

This does not mean Kile having 300 bugs! Most findings are harmless, but some real issues might hide between all these findings. Since June I reduced the number of cppcheck findings by almost 200. Thereby, we improved some bad code style and even found real bugs.

Unused variables or unused assigned values

or unused assigned values

or unused assigned values

Unused variables are variables that are in the code but are not used. Closely related are cases of assigned values, that are never used after the assignment. This should not happen, often it is a result of code changes with no longer variables or assignments left. I removed 17 such cases, and it makes the code clearer to understand.

Case closed? Not so fast. In one instance, it revealed a tiny bug.

01 QString icon;
02 if (ext == "application-x-bzdvi" ) {
03     icon = ext;
04 }
05 else if( ext == "htm" || ext == "html" ) {
06     icon = "text-html";
07 }
08 else if(ext == "pdf" ) {
09     icon = "application-pdf";
10 }
11 else if( ext == "txt") {
12     ext = "text-plain";
13 }
[..]
22 else {
23     icon = "text-plain";
24 }
25 return icon;

Cppcheck complained that in line 12 the variable ext gets assigned a value that is never used. Well, yes, because the value should be assigned to icon like in the other if branches. After fixing, text files gained an icon in Kile's documentation browser.

Document browser has now icons for text files, too. The light gray color is a new feature independent of the issue at hand.

Another bug went unnoticed by me, but Kile's maintainer Michel spotted it.

01 //both exist, take most recent
02 if(read1 && read2) {
03     read1 = file1.lastModified() > file2.lastModified();
04     read2 = !read1;
05 }
06
07 if(read1) {
08     dir = S();
09     trg = "index.html";
10
11    translate(dir);
12    setRelativeBaseDir(dir);
13    translate(trg);
14     setTarget(trg);
15 }

Cppchechk warned that in line 4 the value assigned to read2 is never used. I removed the line, but the actual fix was adding an else(read2) branch. This case was forgotten and spotted with a careful review of cppcheck's findings.

C-style pointer castings

C-style castings are tricky, as they are sometimes a promise from the programmer that the types are compatible and the compiler has no way of checking. With C++ there are five (!) different type of casts, many are not dangerous as the compiler can check the compatibility of what the programming is asking for. For more details, see a blog post from Anteru explaining more details.

Six cases of C-style pointer castings were not necessary and could be dropped. Twelve more could be replaced by C++'s static_casts, ensuring all safety checks from C++ are applied.

Other improvements

Many other improvements made the code more beautiful, like having variable scopes reduced as much as possible. This leads to variables that are only known inside a loop, and that variable declaration and its use stay closer together.

In one case cppcheck found a potential memory leak as a variable was created with new whenever the surrounding method was called, but the object was never deleted.

Two for loops with iterators could be slightly simplified by range-based for loops. The latter prevents off-by-one errors and expresses the intend more direct.

That is all?

I fixed only some of the most obvious findings. I spared the complicated ones, as my understand of Kile's code base is still limited. Further, I did not want to introduce new bugs to not endanger the hopefully upcoming release.

In the remaining cppcheck findings are some more potential bugs, their description looks promising.

Have a look at cppcheck findings yourself!

I can recommend to examine cppcheck findings for your project's, too. At first, it might look like a cumbersome task. I am sure it is worth the effort.

Fixing cppcheck findings is also a good junior job to get in touch with the development of your pet part of KDE. Start with some, not too many at once, trivial fixes and follow the feedback from the maintainer. My experience with Kile was pleasant, thanks Michel!

A new release of Doxyqml is out. Doxyqml is the tool which we use to transform our QML code in non working C++ code, but good enough for Doxyqml to understand it. This power the documentation of Kirigami, Kirigami Addons, Plasma Framework and more on api.kde.org.

This release mainly fix various compatibility bugs with more recent QML versions.

Thanks to Frederik Gladhorn, Joshua Goins, Libor Tomsik, Matej Starc and Nikolai R Kristiansen for their contributions to this release.

Here is the full release log:

• Add support for single quote strings(Carl Schwan)
• Ignore private functions in generated api (Carl Schwan)
• Add support for typed functions (Carl Schwan)
• qmlclass.py::add_import: dynamically get import qualifier (Matej Starc)
• Allow arbitrary default arguments (Frederik Gladhorn)
• Fix wasteful newline if there was no meaningful comment (Joshua Goins)
• Change expected test data to account for the new comments (Joshua Goins)
• Simplify header comments, add version/import at the very last minute (Joshua Goins)
• Don’t parse internal module types (Joshua Goins)
• Use @version instead of @since command (Joshua Goins)
• Add import statements for QML components (Joshua Goins)
• Support array literals as function args (Nikolai R Kristiansen)
• Fixed parsing curly brackets in JS function (Libor Tomsik)

The release can be found on PyPi.org.

F10 for the Main Menu!

We now have a new KStandardShortcut. With https://commits.kde.org/kconfig/782e43f8076e5f4a10111a6b4d2cc6b1741c9798 the F10 key is now assigned to “Open Main Menu”. This is in my opinion a big win for accessibility because up until now for blind people there was no consistent way in our software to open the main menu.

You can see the problem for yourself if you try to get to the menu bar in your favourite KDE application. Notice how you can't get there using the Tab key? You actually need to hold down the Alt key and then use mnemonics i.e. the underlined letter to jump right there. Now blind people obviously can't see those underlined letters or there might not even be a menu bar in the first place so there actually was no reliable way for them to explore all the actions our software had to offer.

So now we decided (or rather I suggested and everyone seems to agree) to have F10 as the key to open the main menu. Why F10 you ask? Well, mostly because everyone else is already using it: Gnome, Microsoft, Chrome/ium, and Firefox (but Alt also works here). We don't want users to have to care which toolkit they use when they just want to open the main menu, so F10 was the logical choice.

However, only deciding on a standard shortcut obviously isn't enough. The opening of the main menu also needs to be implemented. My goal was to implement this for many applications for free. The other goal was to not disrupt those applications too much by taking away their F10 key. Unfortunately, a little bit of disruption is still necessary and this blog is here to announce this.

So considering that we have applications that use the menu bar as their main menu and others that use a hamburger menu and others that might have neither of those or some custom main menu, the best I did for now is to implement F10 to open a main menu in KHamburgerMenu. This is handled as a normal keyboard shortcut that is assigned to KHamburgerMenu by default and which will open either the menu bar or the hamburger menu depending on what the application currently uses. Even if the application currently has both the main menu and a hamburger menu button completely hidden my implementation makes sure that a menu still opens so no blind person ever has to wonder why nothing happened.

All of this means that after upgrading to KF6, pressing F10 in your KHamburgerMenu-using application might have a keyboard shortcut conflict. This won't/shouldn't lead to a crash or anything, just to an annoying popup. This can be avoided by assigning one of the conflicting actions to something else either in application code or by the user.

If an application does not use KHamburgerMenu, there will be no change at all. I would however encourage everyone to make F10 open the main menu for every application. That's typically very easy to implement. QMenuBar for example has a method for this. But honestly, if we are talking about an application that could be using KHamburgerMenu, it might be about as much work to implement a very minimal KHamburgerMenu. In kdenlive they only had to add 20 lines for this: https://invent.kde.org/multimedia/kdenlive/-/commit/cb38d57691cfba311c0e59fd748d88a5b8690ba8 This implementation will allow users to re-assign the keyboard shortcut.

I haven't really checked how to best do this in Kirigami-based applications.

Anyways, with F10 by itself partially dealt with, there is one more F10 related accessibility feature I need to talk about:

Shift+F10 to Open Context Menus!

You see, people who can't use a mouse pointer or other pointing device rely on the keyboard to open context menus. However, many keyboards these days do not have a Menu key. Therefore there is no way to open context menus by only using a keyboard! Well, at least not in KDE applications. Actually, this is again a situation where everyone else has already decided that context menus should be triggered by Shift+F10. This is already recommended by the Web Accessibility Initiative, Microsoft, and implemented in Chrome/ium and Firefox. We are, however, behind on this.

So on to the implementation. Skip to the end of this section if you only want to know what I will be doing and how this might affect your application.

How can I make every application also listen for Shift+F10? It would be really nice if, from one day to the other, all of our software would open context menus on Shift+F10. This can be accomplished by binding Shift+F10 to the Menu key which is surprisingly easy to do even as an end user. If you want to have this functionality today, do the following (not sure if it works on Wayland):

1. Create an .Xmodmap file in your home directory (https://linux.die.net/man/1/xmodmap):

   cd 
   xmodmap -pke > .Xmodmap 
   

   This file will be used to re-assign keys or keyboard shortcuts.

2. Open that file and change the line that looks somewhat like this

   keycode 76 = F10 F10 F10 F10 F10 F10 XF86Switch_VT_10
   

   to this

   keycode 76 = F10 Menu F10 F10 F10 F10 XF86Switch_VT_10
   

   Replacing this second occurrence of F10 in this line with Menu will tell the software Xmodmap that from now on, pressing the key with the keycode 76 simultaneously with Shift should be translated to a Menu key press.

Delete this file later if you don't want key re-assignment anymore.

Now obviously this means that no software anywhere will be able to use Shift+F10 for anything. Or rather: It will always be interpreted as a Menu key, so the Menu key and Shift+F10 would always do the same.

Honestly, it might be a bit rude to take away Shift+F10 from all software, but I am not sure if this would even be a problem. I kind of doubt that there are many applications that have any crucial functionality on Shift+F10 and do not allow to re-assign this. If this was the only downside to this approach, I might have tried to convince the wider KDE community that this or something similar was the best way forward. However, the thing is that this only solves the problem in situations in which we/Plasma have control over the system. This won't fix any of our software when it is used in a system in which one can't interpret Shift+F10 as Menu.

A different idea I had, which is a bit more targeted, would have been to instead implement the above as part of the KDE platform. Qt software adapts itself to the platform it runs on, so we have some control there which we can force upon software by implementing a platform plugin (see https://doc.qt.io/qt-6/qpa.html or https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbkeyboard.cpp#n903). This would then only affect Qt software instead of affecting the whole system, but once again: This only works as long as our software runs on a platform that we control.

So this needs to be implemented on a non-system layer. Frameworks perhaps? What about interpreting Shift+F10 as Menu through an EventFilter on top of the QApplication?

This works and is portable but I would still take away softwares' autonomy to use Shift+F10 as they please (or at least require them to opt out). It is also not nice for performance reasons because such an EventFilter will slightly slow down every user interaction with the application.

Okay, let's try to be even more cautious and choose a different implementation. Let's simply override QMainWindow::keyPressEvent(). Unfortunately this means that only key press events on children of QMainWindow can be handled. Key presses on secondary windows the application might have won't be within our grasp. However, on the plus side, key presses will only arrive at this method if they hadn't be handled by the application already. So we wouldn't be taking away Shift+F10 from the application! Good news!

So this is what I am going to do: I will override the QMainWindow::keyPressEvent() in the KXmlGui framework so that we post our own context menu events whenever a Shift+F10 key press comes in. This works pretty well so far from my testing. It doesn't always work unfortunately because the context menu opening was, in some cases, implemented in a way that expects either right-clicks or Menu key presses in a hard-coded way. They don't react to QContextMenuEvents as they should. So in those cases I might adapt some widgets so they behave nicely.

This will result in applications using the KXmlGui framework reacting to Shift+F10 by opening context menus if the applications don't already handle or use Shift+F10 themselves. If applications really absolutely do not want anything to happen when Shift+F10 is pressed, they can filter these events out beforehand.

Shout-out and Thanks

This work is being supported by the NLnet foundation and the European Commission! The project I am being funded for isn't really specifically about accessibility, but the people at NLnet are so nice and forward-thinking that I am allowed to do a good amount of work on improving accessibility in Dolphin as part of my grant. As is the nature of open source, in this case many KDE applications will benefit from this work.

I also want to mention Fushan Wen here even though he had nothing to do with any of the work mentioned in this blog post simply because he has been doing outstanding work for accessibility in KDE for many month now.