Most of our desktop applications have a toolbar, sometimes they even have multiple toolbars next to or stacked on top of each other. More complex desktop applications such as Krita, Kdenlive or LabPlot often consist of multiple sub-windows, docks, tabbed views, etc. Docks and toolbars can be undocked, moved around and arranged freely and when dragged over a part of a window snap back into the window. This allows the user to customize their work environment to their liking and needs. This worked fine on X because it lets you do anything, this post explores the situation on Wayland.

The current situation

Lets start with a more familiar example, tabs in applications such as web browsers can often be dragged between different windows of the browser and when dropped somewhere else they become their own window. Dragging a tab out of Chrome creates a new window that follows the cursor and it is seamlessly integrated back into other Chrome windows when hovering over their tab bar. When doing this in a Wayland session it tried to do the same, starting a drag operation and creating a new window, when the cursor goes back to the bar the window is reincorporated. Except that clients can’t position their own windows on Wayland leading to sub-par UX. So it creates the window which the compositor places somewhere according to its policies. This window does not move around with the cursor but vanishes when the cursor enters the tabbar of another browser window. This feels weird and broken.

Qt exhibits similar behavior to Chrome when trying to drag around toolbars in a Wayland session, they detach and appear in the middle of application but the app itself reacts as if the toolbar is being dragged around and you could reattach it in some part of the window. However since they don’t have any window decorations, once detached they can only be moved around by compositor specific means like pressing Alt and dragging when using KWin. Dragging the cursor on the displayed move handle starts the “app thinks the window moves but it isn’t” state again and it may be possible to drag it back to its window. ‘May’ because this feels even weirder than the initial action since the app can’t know on Wayland where the toolbar window was in relation to the other window . Detaching a dock results in the same experience, except that once it is detached it is actually impossible to dock it again. Floating docks receive a system titlebar so at least can be moved around more easily but contain no way to start the docking process again. This is also weird and broken.

This problem is one of the last remaining blockers for some of our more complex applications in KDE for switching to Wayland by default. While some workarounds (such as the one outlined above) exist, a proper solution is needed.

The solution

Facing this shortcoming a new extended drag protocol was proposed and implemented by Chrome developers in 2020 but unfortunately the effort stalled. My initial impression was that it provided a good starting point but maybe sometimes a bit complicated. Nevertheless I started to prototype an implementation in KWin and although not even Chrome implemented the more involved parts of the protocol I had working tab dragging not soon after. Encouraged by this I implemented the minimal client parts in Qt and could successfully drag toolbars and dock widgets around. This convinced me that a more focused protocol would be sufficient cover the different use cases.

A bit of trimming, renaming and shuffling things around resulted in the xdg-toplevel-drag protcotol. The idea behind it is that the application can attach a window to a drag operation which then the compositor moves around with the cursor. The advantage of using the existing drag mechanism is that the window under the cursor is informed of the cursor position while a normal window move does not provide any information to it. The application can then also use the normal drag and drop negotiation mechanisms to infer the state and choose an appropriate action. For example the drag being accepted means it is over an area that will incorporate the window. It’s up to the client to take immediate action or not, Chrome will move a tab to a window the moment it reaches its tabbar while Qt just shows an indicator and waits for the drop to perform any action. When a drop happens but the drag is not accepted the cursor was over some other area and a likely (non-)action of a client would be to keep the window that was being dragged around alive.

The above shows the mentioned protocol in action inside Qt and KWin. I also went ahead and added support for the newly proposed protocol to Chrome since I iterated on their original work. But it also shows that the same protocol also works for its slightly different use case of attaching and detaching tabs during the ongoing drag. Below you can see Chromium using this new protocol inside KWin.

The way forward

This work addresses one of the main blockers for our Wayland session that we want to solve in time for the initial Plasma 6 release. Due to timeframes we know that Plasma 6 is likely to require Qt 6.6. However the feature freeze for Qt 6.6 was already in June and the protocol was not accepted at that time. To ensure the functionality is available for our deadlines the Qt implementation that is shown in this blog post was merged under a different name (changing thexdg prefix toqt). The intention here is to change it back once as soon as possible when the upstream procotol is accepted. So the applications relying on it work perfectly not only on Plasma but also on all others desktops.

Discuss this post on KDE Discuss.

There is a term, that in recent years my brain is using a lot when trying to explain to me what my eyes observe. Late-Roman Decadence. I am not a historian, so I might be inaccurate with its actual meaning. For me it just means "wasting because we can". If you want to see this in action, delete your YouTube cookies to get out of your tech bubble and open its start page. Probably depending on your location, it's all about eating the biggest meals for 9000€, driving the fastest cars for 777k€, destroying expensive things in the most hilarious ways for 2M€ as well as giving homeless people 100€ and filming them at whatever they do with it before they fall back into their own life of being spat out and ignored by society. For me: disgusting and worth another strategically well sized and well placed comet.

But that's just the depression speaking. So let's not look at the world, let's look at and try to tackle my own little problems.

I like to have my laptop efficient and quiet. No fan, no moving parts that "klack" or whatever. Just silence. Bonus points if the AC adapter does not emit high-pitched buzzing. My ears are broken and very sensitive to noise. But I also like to have a machine that is as low-spec as it can be. Using less resources should be a good thing, right? So currently I am using an Acer Swift 1, which comes with an N6000 1.1GHz CPU and 8GB of RAM. This is fine for me performance-wise and I can have my usual 5 to 10 applications running with no problems at all. It even plays many of the coop games, my girlfriend comes around the corner with once in a while. For KDE work, the translation summit workflow is one of the things I tend to wait for. It would of course be faster on a higher spec'ed system but it takes around 20 minutes with Fedora and around 4 minutes with Debian on the same machine, so other factors than hardware seem to play a big role in this story as well. Also, I can still have that laptop at the... well... top of my... well... lap without burning my legs or making my blanket smell funny.

On a side note, this laptop sucks in other ways. It cannot do suspend properly. If it wants to go to sleep it immediately wakes up again with full display brightness and it repeats that every few minutes. Acer support says: no Windows, go fuck yourself. (Disclaimer: They did not actually say "go fuck yourself", they just stopped responding once I mentioned Linux.) Also the touch pad is only recognised as PS/2 device and lacks all gestures like scrolling and such. (Yes, I learned to use scrollbars again and hate scroll indicators that are thin or hidden.) Again, without Windows, you do not have the right of owning properly working hardware. I spent weeks looking into these two issues but none of the proposed solutions I found worked for me, either because they only work on Swift 3 and upwards with more settings available in EFI or they just did not do for me what they did for some other people. But broken hardware being sold and then fixed with Windows drivers is a completely different topic I do not want to delve into. Back to what I want to talk about. Buying another passively cooled laptop in the future. So what is the market up to?

Due to the bad Linux experience with the current Acer laptop, I decided to specifically look for Linux devices. Tuxedo to the rescue! Let's look at their current lineup. The InfinityBook 14 v2 was passively cooled but it is not in stock anymore and according to their support, there are currently no plans for new passively-cooled laptops. OK, so ... what are they up, then? In their latest news, they show a Stellaris 17 - Gen5 ... with absolute high-end hardware which needs an external water cooling system to operate properly. One of the key selling points is that the graphics card alone is allowed to draw 175 watts. Let's burn the planet ... because we can!

I do not want to pick at Tuxedo here in particular. The processor vendors are playing the same game for years. If they can gain 5% performance by increasing power consumption by 30%, they will do it. Complete nonsense, but it sells. Bigger, faster, louder. Let's make sure nobody realises that a 1GHz CPU and 8GB of RAM might be enough for 90% of the people. Instead, make the people think they are missing out so they consume without thinking about their actual needs. The same success story the car manufacturers are wallowing in with their SUVs. Let's burn the planet ... because we can!

So, what now? "Everything's fucked" is not a healthy attitude. But trying to change things seems impossible because of all the "not listening" you get when trying to talk to vendors about it. ... Yes, even from small vendors.

I will continue watching the Tuxedo space because I would like to support what they are doing (Linux-wise, not Hardware-wise). I will also keep an eye on AMDs Ryzen Embedded R1305G CPU and its close friends. Maybe some laptop manufacturer will be stupid enough to put it in one of their models. They could at least sell one of them. My backup plan is to buy a laptop with e.g. a low-spec Ryzen U series CPU and hope the fan can be made shut up with energy profiles and disabled boost and such. But that feels like wasted resources again. I will also continue to write to laptop manufacturers even if they do not even bother answering because my desires are too non-mainstream and as such too expensive to deal with. ... But I also ask myself, why bother at all. If the majority of our society (I am talking "western" here but the rest of the world is catching up quickly) is happily burning the planet for no reason but the fun of it, why am I trying to disagree and having a hard time? Why not just party along and wait for the cleansing comet? ... I guess it is one of life's challenges to find an answer to that question.

I tooted posted on Mastodon about how it would be great if more open source project would adopt REUSE.

Someone pointed out that it would be great to automate the addition of the metadata inside the files based on the git repository.

So here is a small script that does exactly that. It goes over all your .cpp and .h file and will add the header based on the list of authors as well as the first commit on that particular file.

You will want to adapt it to the license you are using for your project as well as change **/*.cpp to **/*.py if you are doing Python development.

#!/usr/bin/env bash
# SPDX-FileCopyrightText: 2023 Carl Schwan <carl@carlschwan.eu>
# SPDX-License-Identifier: MIT

for file in **/*.cpp **/*.h;
do
 year=`git log --format="format:%ci" --reverse $file | head -n1 | cut -d "-" -f 1`
 git shortlog -n -e -s -- $file | cut -f 2 | while IFS= read -r author
 do
 reuse annotate --copyright "$author" --year "$year" --license "GPL-2.0-or-later" $file
 done
done

This is not perfect and you want to run git diff before commiting the result, to check if the change made are fine.

At KDE we make software for many different platforms. One of them is Microsoft Windows. But what if an application crashes on Windows? New tech enables us to track crashes right in Sentry! Time to learn about it.

When an application crashes on Windows the user can submit crash data to Microsoft. Later KDE, as publisher of the app, can retrieve the crashes from there. This is the standard crash handling for the platform and it works incredibly well. What’s more, it means we don’t need to engineer our own custom solution for the entire process. So, that is all lovely.

Alas, since we are rolling out a KDE-wide crash tracking system called Sentry it would be even nicer if we had Windows crashes in there rather than third party service. That is just what I’ve built recently.

Crashes for our Windows applications now get imported into Sentry!

There are two pieces to this puzzle. One is a symstore and one is the actual importer.

Symbol Storage

In the Linux world we not so long ago grew debuginfod, it’s basically a tiny service that lays out debug symbols in a standardized file path so it may be consumed by any number of tools by making HTTP GET requests to well-known URIs.

Windows has something like this called symbol storage. It’s incredibly simple and merely lays out Windows debug information in a well defined path setup for consumption in tools.

To maintain a symstore of our own we use the excellent python module symstore along with some custom rigging to actually retrieve our debug information files.

Import

The second piece is our importer. It’s a trivial program that uses Microsoft’s APIs to retrieve crash data along with the minidump (the dump format used by Windows crashes), converts it into a Sentry payload, and sends it off to our Sentry instance. Sentry then consumes the crash, does symbolication using the debug symbols from our symstore, and generates a crash event.

Support

If you are shipping your application on the Windows Store you should consider publishing your dbg.7z files on download.kde.org (for example here is Okular), simply file a sysadmin ticket same as with any other upload to get this published. Once that is done you can submit a change to our symstore to publish the debug symbols, and our importer to import data into Sentry. If you need help just give me a poke.

If you are publishing builds for Windows but are not yet on the Window Store, you definitely should change that. It increases your application’s reach considerably. Get in touch with sysadmins to get yourself set up.

Importing crashes into Sentry adds another piece towards higher quality, more actionable crash reports. It’s going to be amazing.

Discuss this blog post on KDE Discuss.

Let’s go for my web review for the week 2023-31.

The BBC on Mastodon: experimenting with distributed and decentralised social media - BBC R&D

Tags: tech, fediverse, attention-economy

Welcome to the Fediverse! It’s just an experiment for now, let’s hope they stay longer.

https://www.bbc.co.uk/rd/blog/2023-07-mastodon-distributed-decentralised-fediverse-activitypub

Sci-Hub’s Alexandra Elbakyan Receives EFF Award for Providing Access to Scientific Knowledge * TorrentFreak

Tags: tech, foss, science

This is well deserved. She’s doing a very important work for the progress of science. All those pay walls are nonsense.

https://torrentfreak.com/sci-hubs-alexandra-elbakyan-receives-eff-award-for-providing-access-to-scientific-knowledge-230728/

Tor’s shadowy reputation will only end if we all use it | Engadget

Tags: tech, anonymity, surveillance, tor

Indeed, we need more traffic going through Tor if we want to keep it effective.

https://www.engadget.com/tor-dark-web-privacy-secure-browser-anonymous-130048839.html?guccounter=1

“Web Environment Integrity” is an all-out attack on the free Internet — Free Software Foundation — Working together for free software

Tags: tech, foss, google, browser, surveillance

The FSF words are strong but deserved in this case. Let’s hope it marks the beginning of an efficient campaign against this move from Google.

https://www.fsf.org/blogs/community/web-environment-integrity-is-an-all-out-attack-on-the-free-internet

Google’s Plan To DRM The Web Goes Against Everything Google Once Stood For | Techdirt

Tags: tech, google, surveillance, attention-economy, security

Good explanations, the parallel and history perspective on Palladium is right. It’s the same fight than 20 years ago, it shows up its ugly head regularly. Time to collectively say no once more.

https://www.techdirt.com/2023/08/02/googles-plan-to-drm-the-web-goes-against-everything-google-once-stood-for/

Splitting the Web

Tags: tech, web, attention-economy

Interesting point of view. We have two worlds now coexisting on the Web and they tend to ignore each other more and more.

https://ploum.net/2023-08-01-splitting-the-web.html

From Napoléon to Macron: How France learned to love Big Brother – POLITICO

Tags: tech, france, surveillance, politics

Welcome in France, this country which claims to be a beacon for Human Rights but has a problem with its law enforcement for the past two centuries… surveillance abounds and its accelerating.

https://www.politico.eu/article/france-surveillance-cameras-privacy-security-big-brother-paris-olympics/

The Reluctant Sysadmin’s Guide to Securing a Linux Server

Tags: tech, server, self-hosting, security

This is a good list, should be seen as a starting point there are more things to do after this. I’m thinking for instance about adding fail2ban to the mix.

https://pboyd.io/posts/securing-a-linux-vm/

What’s in a Module? · thunderseethe’s devlog

Tags: tech, design, architecture, modules, programming, language

Interesting look at module systems and what they entail. It’s funny to see that most languages do things slightly differently in this area.

https://thunderseethe.dev/posts/whats-in-a-module/

Making the Global Interpreter Lock Optional in CPython

Tags: tech, python, multithreading, performance

OK, this could be big for Python. Let’s see how they execute this plan. It carries some risks as well, but they seem well aware of them.

https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474

Overloading arithmetic operators with dunder methods | Pydon’t 🐍 | mathspp

Tags: tech, programming, python

Nice summary of everything you can do with operators overload in Python.

https://mathspp.com/blog/pydonts/overloading-arithmetic-operators-with-dunder-methods

A Blog Post With Every HTML Element - Patrick Weaver

Tags: tech, web, frontend, html

A little experiment which turns into a neat reference in HTML elements. Could be useful.

https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/

Git files hidden in plain sight 🫥 - Tyler Cipriani

Tags: tech, git, funny, tools

Funny what you can do with Git at a lower level. 😊

https://tylercipriani.com/blog/2023/07/31/git-files-hidden-in-plain-sight/

Jujutsu: A Git-compatible DVCS that is both simple and powerful

Tags: tech, tools, git

Looks like an interesting alternative to Git. To investigate I think.

https://github.com/martinvonz/jj

Retrospective Prompts

Tags: tech, project-management, retrospective

Interesting set of follow up questions during a retrospective.

https://two-wrongs.com/retro-prompts.html

On levelling, learning and development - Robbie Clutton

Tags: tech, management, career, hr, learning

Interesting to look at several career progression models and compare them indeed. This is likely necessary when making your own model for your context.

https://blog.robbieclutton.com/p/on-levelling-learning-and-development

Netscape Meteors - Eryn Rachel Wells

Tags: tech, browser, history

Nice trip down memory lane. Interesting conservation work in any case.

https://erynwells.me/blog/2023/08/netscape-meteors/

When the wizards of the web met - The History of the Web

Tags: tech, web, history

Nice recounting of the first meetings to make the web what it is today.

https://thehistoryoftheweb.com/postscript/when-the-wizards-of-the-web-met/

Bye for now!

(German version of this post: https://wordsmith.social/felixernst/akademy-2023)

37 °C were the average daily temperature heights during the Akademy week in Thessaloniki. When you walk outside at these temperatures, your first thought is that you would rather go back inside. This used to be a temperature that one would hardly ever see there. 38 °C has not been exceeded in Thessaloniki in the 5 year span 1980 to 1984. But actually we were lucky, because the real heat wave only came around when we already left with around 44 °C in Thessaloniki and forest fires everywhere. It is a shame that with the current global political landscape none of this seems likely to become any better (to put it mildly) within our lifetimes. The nature in Greece is very nice aside from that.

But I think I have already exceeded my doom quota for this report, so back to brighter topics like the KDE community!

Meeting Everyone

I usually throw myself into these events, talking to everyone I haven't met yet and doing my part in making sure everyone feels welcome. It was especially interesting to talk to the local Greek students attending the event. One of them is already making attempts at contributing to Dolphin. I don't want to praise and pressure him here by saying his name already, but if you see a new Greek name on “This Week in KDE” in the next few weeks/month, you will know.

Some of the Greeks were part of the key note presentation “Libre Space Foundation – Empowering Open-Source Space Technologies”. Their passion for bringing their open source software to space was contagious.

I, on the other hand, am still stuck on this planet that gets hotter by the day. Did I mention the heat already? Oh right, back to topic…

Since becoming a maintainer of the Dolphin file manager about a year ago, I try to look out for the long-term health of the project. In that regard, I had an idea about how everything could go horribly wrong at this years Akademy:

Meeting the Other Dolphin Maintainer

I had never actually met the Frenchman Méven Car, who I share maintainership of Dolphin with. We hardly sent any direct messages to each other ever and none of them before April this year. All of this might seem strange considering that we have worked on Dophin together for a while now, but it also shows that one doesn't need to work behind closed doors to bring software forward. The most important aspect is having an atmosphere in which the technical and UX merits of work can be discussed honestly and without fear.

So one possible way our first meeting could go was, that we loathe each other. The next logical step would then be that we don't trust each other to be good stewards of the Dolphin project. One of us then creates a competing fork, which follows a different but similar vision, and in the end Dolphin would be stuck in an unpleasant atmosphere of hostile accussations and bad stability, eventually leading to its demise into irrelevance. ?

In actuality, this didn't happen though. Phew!
But the above paragraph was the first story I told him.

We actually get along very well and had much time to talk about matters pertaining to Dolphin. It doesn't really seem like we have different ideas about what work needs to be done for further world domination.

Speaking of which:

Dolphin's Strategic Position

At last year's Dolphin meeting I had already tried to figure out the biggest areas of improvement by making this the headline of the meeting. Read all about it over here.

By this time, it seems like we are aware of most aspects that are still lacking in some regard. I am not really encountering a lot of fundamental criticisms anymore that I am not already aware of or which we don't know a way forward with. Most of the time we are lacking the work force to fix the more long-standing issues soon™.

Some of these were discussed at the Dolphin meeting at Akademy.

Especially Dolphin's search functionality was a big topic. It is kind of sad that people can't always rely on the Dolphin search to quickly find their files. This is partially for technical reasons, but also for user interface design reasons. You can read all about it here: https://invent.kde.org/system/dolphin/-/issues/46 Currently we are looking for a clear direction when it comes to the Dolphin search UI. You can find a mockup I made when you follow the link, but as long as nobody else is commenting on it or bringing their own design, there is no consensus. There are a lot of more technical background topics that need work as well though.

I was also wondering what Dolphin can gain from trying to break out of the Linux/Unix eco-system. Projects like Krita and Kdenlive were successfull in finding a user base outside of Linux. Dolphin is already one of (or even) the most popular file manager(s) on Linux. How much room for growth might there be if Dolphin's Windows version were more polished and visible for Windows users? Currently we don't seem to have people who want to fix bugs for this proprietary platform in their free time. Similar things could be said about a Mac or potential mobile version of Dolphin.

In line with KDE's current goals we also talked about improving testing using Selenium and AT-SPI. There is already some progress on this. Next there is the accessibility goal, for which I can point to a merge request I started creating while in Greece: https://invent.kde.org/system/dolphin/-/merge_requests/577 There is however still a lot of room for improvement when it comes to accessibility in Dolphin. Most annoyingly the “Back” and “Forward” buttons can currently not be focused using the Tab key. More contributions are always welcome in that regard. After attending all the talks about accessiblity I could find at this year's Akademy I feel a lot more confident about being able to review such contributions.

Méven has covered some more Dolphin topics in his article, so I will refer you to it: https://www.bivouak.fr/dolphin-at-akademy-2023/

Aside from Dolphin

…there is a lot more to talk about. So much more actually that it is becoming very apparent to me that I should probably cut it short now. Many of the talks are available on Peertube.

One more talk I want to highlight is “Make it talk: Adding speech to your application” by Jeremy Whiting. That one was about using speech more often in applications. I liked that talk not necessarily because I think there was a good way to add more speech to Dolphin in particular, but because it encourages improvements to tried and old basics of application design. If there was a “Speak” button next to this text you are currently reading, you would be able to transform this reading exercise into a podcast-like experience and a five-year-old kid could have listened along (and be bored about the tech-speak). I think a similar talk could be made about using animations for improved clarity when the state of an application or some data changes.

Thanks to the people who made this possible

Akademy would have been a very lonesome experience if we didn't have donors, sponsors and volunteers allowing everyone to come together. I am not sure if an international community like us could function long-term without such meetings. It gives me hope when people from eight different nations can sit at one table, talk about politics and still have a good time.

After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.

About

What are Input Methods?

Input Methods are a way of allowing third parties programs to manipulate text in text input boxes in applications.

The two traditional uses of this are on-screen keyboards like one has on a mobile phone, and Chinese, Japanese and Korean (CJK) input where a keyboard doesn't map directly to the text we want to see on screen.

It's a lot more than merely injecting keys; the input method needs to have an awareness of the text cursor and the ability to manipulate whole words and sentences at a time. This is extremely important for the CJK way of typing where multiple keyboard keys are used to compose a single character. It's also important for virtual keyboards that have advanced features like auto-completion and spell-checking words.

X vs Wayland

On X11, the standard protocol (XIM) is hardly used, we ended up with every input method creating a plugin for every toolkit. This sufficed, but was not very scalable, doesn't have the best desktop interaction, and is messy to deploy.

The story with wayland is also far from perfect. With the compositor acting as a broker, we have a protocol from the plugins themselves (InputMethod) and protocols to clients (TextInput). Unfortunately there are at least 6 active versions of these protocols, which needs some work.

A recent meeting with other wayland devs has hopefully helped agree on a path forward for the TextInput side, with me taking on a lot of active tasks moving this forward. But we still need to sort out the InputMethod side.

I used Akademy to speak to people using CJK input and got very valuable feedback about the Korean language and some changes needed to make FICTX work properly there.

If you have experience with Chinese or Japanese input on wayland, please do reach out.

A Playground of Input Method Ideas

I don't use CJK keyboard entry nor a virtual keyboard on a daily basis, but there are things I do use that could benefit from the InputMethod tech. Now we have a standard we can look at using this stack for more creative ideas. Doing this now can help work out what the requirements are for the protocols as we stretch it in new directions.

This post describes some ideas of how else we can use Input Methods to improve the Linux desktop experience.

Convenient Clipboard Connections

With a shortcut we can enter clipboard entries, previewing in place. We're able to use the preedit text to display metadata on available entries which won't get committed to provide a streamlined interface, or we could bring up a menu, or both.

Compared to the existing klipper integration we can open at the current carret position, and provide something a bit more streamlined. The preview also helps solve the frustrating problem of pasting only to find you've now got too much or too little whitespace where you hit paste.

Easy Emoji Entry

My attempt at understanding young people. Typing ':' and then a string launches an inbuilt emoji browser based on the typed string.

These days a lot of clients now have in-built support, including all GTK4 text areas, so it might not be needed. Maybe the ship for this has sailed, or there could be still value in centralising it and having a common pattern.

Direct Diacritic Display

Building on an existing merge-request by Janet Blackquill, pressing and holding a key will bring up a prompt with relevant characters based on the held key.

The original version merge request injected itself into the application repurposing a hook meant for themeing, this broke too many clients to be released as part of Plasma and it was unfortunately reverted.

Taking that idea but using input methods should avoid those problems, whilst also solving the issue of key-repeats being sometimes needed.

Timely Translation Tasks

This was solved by having a second text field open when activated where the user can type their native text, so the translations can be shown in the main text area. The current code utilises the command line tool "trans" which in turn makes web requests to proprietory web services, but we could look at other options if we turned this into a product.

Simply Speak

The one I'm most excited about. Working local dictation software that can integrate into every textfield out of the box.

I got best results using whisper-fast with a voice-activity filter on top. This was wrapped into a daemon with a DBus interface we can then use to start and stop on demand. It needs some work to be a shippable product.

Current State

All of the above are fully working examples, but everything was pieced together in a few evenings at Akademy and some time at the airport.

It's not something I would ship to users; the point right now is to be a playground, uncover issues throughout the stack, and try a few different things. That's why we use different techniques for bringing up the input methods and prompts within it rather than trying to be coherent.

That said, I have made an effort to separate the high level application code from the wayland boiler plate so we can quickly iterate to InputMethodV3 to see what's needed, and turn this into a product as we start to come up with a long term direction.

Running it for yourself

The repo exists at https://invent.kde.org/davidedmundson/inputmethod-playground the readme has instructions on how to get set up.

What does it work with?

A form of TextInput is supported in almost all toolkits from Electron, GTK, Qt, SDL and more. This means it's fairly universal across wayland clients.

On the compositor level, InputMethodV1, the only specification in upstream protocols, is supported by only Kwin and Weston, but as noted in the intro this is subject to change in the future.

Future

The playground has exposed several pre-existing deficiencies, especially regarding the placeholder text styling, input panel positioning, key repeats. We can take those forward into fixes that might affect the more important CJK input methods.

As well as being a playground I think there are some ideas worth exploring further, to find a path into the desktop and is yet another reason to be excited about the path to Wayland,

Have more ideas? Let us know in the discussion at http://discuss.kde.org.

Every once in a while I hear developers having trouble staying up to date with KDE Discuss(ions). No great surprise when I then find out they aren’t tracking things (in other words: not subscribed to categories)!

Discourse, the software that powers KDE Discuss, has a number of handy notifications settings that we can use to have the software bring posts to us instead of having to go to the website every once in a while. We can use these options to tailor a good experience for ourselves.

Three setting types are relevant for the notification experience:

Tracking

Tracking preferences control which discussions to track. Settings here range from when automatic tracking happens - such as when you view a topic for a couple minutes it automatically becomes tracked - to ignoring things. You can track categories as well as tags. Say you only care about kdenlive you can simply track the kdenlive tag and you are good to go.

Emails

Emails contain the second most relevant pool of preferences. There are two principal modes of operation:

• Forum mode
• Mailing list mode

The names should be obvious enough, the functionality probably less so. In forum mode tracking preferences apply and you get emails for posts or threads as configured. In mailing list mode only negative tracking preferences apply! You get an email for every post on the entire site unless you’ve opted to mute something. In both modes you can simply reply by email to post a reply.

Notifications

These preferences have to do with live notifications i.e. if you have a browser open it will throw up a system notification when new posts happen. The settings here aren’t terribly interesting unless you always have a browser tab pointing to KDE Discuss. If you do, you can set a time frame for notifications such that you don’t get notifications when you are at work-work for example.

Recommendations

So, what do I recommend you do?

First off, if you want to keep things low-volume make sure you have the email preference Activity Summary enabled. It sends a summary email once a day with tracked topics. You can disable most everything else. You definitely want to set up tracking for what you want to receive in your summary (unless of course you want to see all threads). e.g. if you only care about dev topics then set the Development category to tracking.

One step up from the summary is actually the default mode of KDE Discuss. By default if you simply configure tracking as desired you’ll get a reasonable mix of notifications and a summary if you haven’t been around in a while.

The most intense setup is to activate mailing list mode. This operates like a mailing list and causes the highest volume of emails. You’ll want to set up email filtering to go along with this. I would definitely not recommend this unless you really care about all discussions on the entire site.

You should also note that you can reply by mail to threads, regardless of whether mailing list mode is enabled. It’s amazing!

And lastly: you can configure most anything, so if you find that you are getting too many emails or too few just head to the preferences and play with some of the options. I’m confident everyone is able to find a good mixture that makes the most out of KDE Discuss :)

Discuss this blog post on KDE Discuss.

The month of July is already wrapped up, I can’t believe it! I went to Akademy this year, and it was really great! Between Akademy and the imminent gear release, I didn’t get much work done this month - but oh well.

I also closed the majority of my old MRs, which either aren’t needed anymore or not applicable. Whats left is features that are still on the backburner (like tablet dial support, Kirigami context menus, etc) that I want to finish.

Tokodon

The next release of Tokodon (23.08) is approaching next month, so I’m focusing on small improvements again. A round of bugfixes for accounts, the fullscreen image viewer not closing, improving the conversation page, removing papercuts for statuses, and making the profile page even better landed early this month.

I have a touchscreen laptop now, and I’ve been able to improve the touch experience for interaction buttons. Expect more touch-related improvements in the future, as before I only had a PinePhone and an Android device to test with. Carl did a lot of profiling work, and I specifically updated the blurhash implementation which makes it oh-so slightly faster to generate. This and the other performance improvements makes scrolling the timeline much smoother.

A big feature I’ve personally been waiting for has now landed, an emoji picker for the status composer! I took this from NeoChat (of course) and slightly modified it for our needs. This is something that could use some improvement in the future, but I’m glad we have this now.

Another smaller but great feature is that account mentions now open inside of Tokodon (like hashtags do already) without kicking you back to a web browser.

PlasmaTube

This is something I’ve wanted for a while now, watch indicators now work for logged in Invidious accounts! These are synced to your Invidious account, so they show up on the website and other 3rd party clients. Partial watches are not yet supported, but I do have an idea of how they could work. Eventually, I want to expose a way to mark videos as “unwatched”.

I also added pagination for the subscription feed but the merge request is currently awaiting review.

NeoChat

Three small changes to NeoChat this month, I fixed the emoji popup shadows and added a more obvious upload button for avatars. And finally gave NeoChat the prettier notifications, like I did for Tokodon last month.

Gamepad KCM

The Gamepad KCM is being prepared to enter KDE Review soon! See the current repository and it already runs in Plasma 6. Jeremy Whiting and I have been working to get the KCM in a nicer state, see my merge request overhauling the C++ backend (I still need to finish it…)

While the KCM isn’t perfect yet, I’m hoping to get it in a “good enough” state to attract more help. If you are interested in fixing the design, code, or drawing controller SVGs we welcome your help!

Akademy

Since I arrived late to Akademy, I only attended BoFs and didn’t have the chance to view the talks. I plan on detailing more of my trip in a future post, but I haven’t had the energy to write.

I went to Carl Schawn’s Plasma Mobile BoF, and the “Contributor On-ramping” BoF held by Joseph De Veaugh-Geiss. It was good, but I arrived late and wasn’t able to catch much of it. I also went to the Plasma 6 BoF afterwards, but most of the time was spent talking about the release date schedule. One of my favorite BoFs was probably Joseph’s Wiki BoF. There was a surprising number of people and it was very productive. We decided on a lot of things: getting on the same page about techbase/userbase (and the problems with keeping them around), removing the wiki theme, and more. You have probably noticed some of the changes even now!

On Thursday, I attended Carl’s Accessibility BoF. I learned how to use Accerciser, and I noticed some accessibility issues in Tokodon which are fixed now! I also spent some time on Thursday improving the Matrix page, which I’m very happy with. I also hooked up with Volker Krause to help Tokodon on Android along, which is now fixed. (Thanks so much!) We also discovered an error in the Android build documentation, as it turns out the docker registry version of the images is no longer maintained. That caused a bunch of issues since NDK paths changed since the old Docker image was updated, which Volker fixed.

It was nice meeting everyone at Akademy, I wish I came sooner because I didn’t have the chance to talk to some people. See you next month!

A neat trick to debug the keyboard navigation in your QML application is to put the following code snippet in your main.qml:

Kirigami.ApplicationWindow {
 ...

 title: activeFocusItem + " " + (activeFocusItem ? activeFocusItem.Accessible.name : "")

 ...
}

Afterward, then you open your application, you will see the following in your title bar:

“PrivateActionToolButton_QMLTYPE_XX(0x00000000)” is the type and address of the actively focused item and “Sort” is the accessible name of this item.

If you tab around your application, you will be able to identify multiple issues quickly:

Missing Accessible.name

You might notice that some elements only display their type and address but accessible name. It is an issue because this means the screen reader user won’t have any clues about what the button does.

If this is the case, ensure that your control has a text property set even if the control itself overrides the contentItem or is an icon only button. If you can’t use the text property, try to set the Accessible.Name property instead.

HTML code in your text

If you see some HTML code appear in your toolbar, it is an issue. Screen readers will be confused by the random XML tags in your text, so make sure to remove them from the Accessible.Name. A simple fix which works in some simple cases is to do the following to clean up your text:

QQC2.Label {
 text: "Hello <b>World</b>"
 Accessible.name: text.replace(/<\/?b>/g, '')
}

Not clear Accessible.Name

By default, your Accessible.name of your controls is bound to their text, which is a good default but you shouldn’t hesitate to add some mode details in your Accessible.Name.

One example, I had in Merkuro (formally known as Kalendar) was in the month view. There each day had as text the month number. In this case, it’s better to expose the whole date to the accessibility API, because without, context a number is not that useful.

Focused but not visible

Some items are focused but are not visible on the screen. This often happens when using a PathView/ListView with only one item visible at the time, since the previous and next item are still loaded. If this is the case, ensure that activeFocusOnTab is set to false, when the item is not visible.

Focused but no visual indicator

Some items are focused but they don’t have a focus indicator. This is an issue since the user won’t able to know which item is currently focused and then pressing space they might trigger a random action.

There is an helpful property in QQC2.Control named visualFocus which should be true when the user uses keyboard navigation to focus on a specific item. So make sure to add for example, a special border when QQC2.Control.visualFocus is true to your custom controls.

// MyButton.qml
QQC2.Button {
 id: root

 background: Rectangle {
 border {
 width: root.visualFocus ? 1 : 0
 color: Kirigami.Theme.highlightColor
 }
 }
}

The type information can gives you a valuable information to find which item is currently selected and has the broken focus.

Focus loop

In some cases, when pressing tab multiple times, you will end up in a focus loop with no way to escape it. This might be caused by broken usage of the KeyNavigation.tab property, dynamic reparenting of elements and other creative ways to break the tab navigation. In case, please fix it!

Unfocusable elements

Make sure all your interactable elements in your application are focusable by default. You can enable or disable this behavior, with the activeFocusOnTab property of Ìtem.