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

The Legacy of Bram Moolenaar - Jan van den Berg

Tags: tech, vim

Nice words about Bram Moolenaar maintainer of vim who passed away recently.

https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/

IBM, Red Hat and Free Software: An old maddog’s view - Linux Professional Institute

Tags: tech, unix, linux, redhat, history

Don’t be fooled of the title. Yes, it concludes about an opinion piece about the latest changes in policy around RHEL. Still, it starts with a very nice retelling of the history around UNIX and computing since the 70s. This is an invaluable resource.

https://www.lpi.org/blog/2023/07/30/ibm-red-hat-and-free-software-an-old-maddogs-view/

Your Computer Should Say What You Tell It To Say | Electronic Frontier Foundation

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

Excellent piece against the Web Environment Integrity proposal from Google.

https://www.eff.org/deeplinks/2023/08/your-computer-should-say-what-you-tell-it-say-1

Blocked by Cloudflare

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

This is based on fingerprinting and sometimes fail. If Web Environment Integrity gets through it’ll be just worse.

https://jrhawley.ca/2023/08/07/blocked-by-cloudflare

Our current FOSS dystopia

Tags: tech, foss, politics, criticism

Definitely this. There’s still so much to achieve through FOSS, lots of missed opportunities. The mentioned factors clearly played a huge part in the current situation.

https://idiomdrottning.org/foss-dystopia

Just normal web things.

Tags: tech, browser, web

Indeed, too many websites or apps break or hijack basic features of the browser. To me it also shows the tension between trying to have a document browser and an application provider shoved in the same GUI.

https://heather-buchel.com/blog/2023/07/just-normal-web-things/

Python cocktail: mix a context manager and an iterator in equal parts

Tags: tech, programming, python

Definitely a clever combination of two Python constructs.

https://www.bitecode.dev/p/python-cocktail-mix-a-context-manager

Reverse Z (and why it’s so awesome) | Tom Hulton-Harrop

Tags: tech, 3d, floats

Good explanations of why you might want to revert the Z axis on your projection matrices. Of course it boils down to how float precision works.

https://tomhultonharrop.com/mathematics/graphics/2023/08/06/reverse-z.html

Remote work requires communicating more, less frequently | Ben Balter

Tags: tech, remote-working, management, communication

Kind of overlooking the cost of producing videos in my opinion. That being said, if you keep videos out of the picture this little article is spot on. Remote work is about more asynchronous and longer form communication first.

https://ben.balter.com/2023/08/04/remote-work-communicate-more-with-less/

I’m taking another short break, so no web review next week!

Bye for now!

I have summarized the entirety of July’s work in a single blog post, as I got quite busy with university in the last few weeks 😢.

Progress made on the Report Moderation Tool

I started with the Report Moderation Tool’s further implementation and managed to implement almost all of the features smoothly. However, I encountered a problem with the self-assigning and un-assigning of reports, which caused the application to crash with a segmentation fault. After dedicating hours to using gdb for debugging, I eventually concluded that the unexpected behavior was likely due to my use of smart pointers. It appeared that the memory was being de-allocated automatically when the object was set to null, and while accessing null when assigning the reports we accessed a null address leading to Tokodon crashing.

I reached out to the maintainers for their help and review on how to fix this issue. I was suggested to try switching to using raw (normal) pointers to address the problem. I tried refactoring the code in a similar way to resolve the issue. However, the transition from smart pointers to raw pointers proved to be more challenging than I had initially anticipated.

I ended up deciding to take a break from the Report Tool and tackle this at the end.

Some images of the (almost)implemented Report Tool

The draft Merge request implementing the Report tool can be found here.

Federation Tool | Manage federation with other servers

Before beginning with the implementation of the Federation Tool Carl pointed out that I was using expensive Q_Object to transfer data from cpp back-end to the QML front-end which was not optimal. So this time I used the QAbstractListModel’s built in functions to expose data to the front-end and realized how excellent Carl’s advice was 🥰 .

I felt more comfortable with the code-base now and can intuitively think about my next steps of action. I took my previously written code as boiler-plate and made the required changes in it to fit with the Federation Tool to finally implement the tool.

Carl also made a new Delegates.SubtitleContentItem delegate UI to display the data in a more responsive and beautiful way and further helped me in implementing this to the Federation Tool.

Image of the implemented Federation Tool

The Merge request implementing the federation tool can be found here.

IP Block Tool | Manage the allowed IPs for your mastodon server

The IP Block Tools implementation was almost similar to the Federation Tools minus a bit of complexity in the data structures used. I used my previously written code as boiler-plate again and built the IP Block Tool on top of that.

Image of the implemented IP Block Tool

The Merge request implementing the IP Block tool can be found here.

Email Block Tool | Manage the email sources allowed to federate

Next tool I started implementing was Email Block Tool. Mastodon provides two kinds of Email block API endpoints: canonical email block and normal email block. Initially, I was skeptical how this would work. However, after further research, I discovered that the official Mastodon website only had the normal email block implemented. I after consulting with Carl, decided to only implement the normal Email Block feature. The canonical email block endpoint didn’t have any clear way to view or manage the blocked emails and would have been confusing for the end user along with the normal Email Block Tool.

The implementation is almost similar to the IP Block Tool and required minor changes to fit the Email Block Tool.

Image of the implemented Email Block Tool

The Merge request implementing the Email Block tool can be found here.

I will be writing regular blog posts on my website. You can read my previous blog-posts and follow my progress here.

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.