KDE Connect was designed 10 years ago (!) with Android smartphones as one of our first supported platforms. Because of that, when designing the KDE Connect protocol we had to work around many technical limitations that Android had back in its infancy.

This year I will be working on a project named “KDE Connect discovery and transport protocol improvements” that received a grant from the NLnet foundation as part of the NGI Assure fund. This grant will allow me to work full time in KDE Connect, with the goal of updating the protocol and apps to modern standards.

Below are the 3 main areas that will improve thanks to this and become KDE Connect 2.0 (even though some changes will show up sooner, because we release early, release often).

Reliability

The strength of KDE Connect (compared to some of the non-free alternatives that popped up in these last 10 years) is that KDE Connect only uses your local network for communication and doesn’t need intermediary servers in “the cloud“. This adds a challenge: devices running KDE Connect have to discover each other in the network before they can talk to each other.

Discovery is possible in the current protocol using UDP broadcasts, but the state of the art nowadays is to use multicast DNS (mDNS) instead, which is more reliable and less often blocked by the network configuration. We wanted (and tried) to adopt mDNS for a while, but it was a a bigger endeavour than what we could tackle.

By focussing full time on this, my goal is to implement an mDNS backend for KDE Connect on all supported platforms (Linux, Windows, MacOS, Android and iOS) before fall this year. Wish me luck!

Security

Before Android 5, only TLSv1 and a limited set of cipher suites could be used. We always try to stay compatible with old devices and to fight the programmed obsolescence that plagues modern technology, but that meant keeping the KDE Connect protocol compatible with insecure encryption protocols.

Starting with KDE Connect v1.22 for Android, we now require Android 5 or later so we can drop compatibility with insecure encryption in all the KDE Connect implementations (and not only Android). In addition to that, we are reviewing and updating the dependencies we bundle as part of the app to make sure we have the latest security patches.

Later this year, and also thanks to NLnet, we will get a security audit by Radically Open Security. This will be the second time KDE Connect is audited, after the openSUSE security team did so in 2020.

Accessibility

We recently adopted Material 3 in the Android app (thanks Dmitry Yudin for doing most of the work!) and KDE as a whole is getting ready to migrate our desktop apps to Qt6. These times are a perfect opportunity to review the accessibility of our user interfaces, and for that NLnet is helping us get an accessibility audit by the HAN University also later this year.

All in all, exciting times for the KDE Connect project! Stay tuned for future updates :)

Testing various functionalities of Tokodon’s Main Timeline.

This is a continuation of my previous blog post where I shared my mid-journey experience while being a Season of KDE mentee.

Week 7-8:

These weeks were spent testing interaction buttons and different types of statuses.

My first task was to write a test for boost, favourite, and bookmark interaction buttons in Tokodon to see if they worked as intended. For this, I identified the behaviour of different buttons using accerciser and then added the missing accessibility description for the respective buttons. I then wrote an appium test as part of TimelineTest to assert if the buttons worked as intended.

Next was testing the different types of statuses, Tokodon has support for two types of statuses normal and spoiler status, spoiler status is just a normal status with a spoiler text and an option to hide or unhide the spoiler text. To check whether the status had a spoiler, I checked if the length of the spoiler text is equal to zero (root.spoilerText.length == 0) if the conditional gave a True value, I assigned the accessibility description(Accessible.description) as Normal Status else a Spoiler Status. The final code for setting the accessibility description was Accessible.description: root.spoilerText.length == 0 ? i18n("Normal Status") : i18n("Spoiler Status");, which I then verified using accerciser if it pointed to the correct place. Once I had the accessibility description set for the respective status, I expanded the TimelineTest to include a new test for asserting the accessible description of the statuses in the Main Timeline, We consider the test as passed if we find the two status types.

Week 9-10:

These weeks were spent fixing the build errors after rebase and checking different types of media-attachments in timelinetest.

My mentor Carl Schwan helped me rebase work/sok/offline-tokodon to the latest master so that I could work on the latest changes, which led Tokodon to stop building due to some build and dependencies error, so the subsequent week was spent on fixing various errors which I tackled by comparing the work/sok/offline-tokodon branch with the master branch and with previous commits, my mentor Carl was always available to give me clues whenever I felt stuck.

Once all the build errors were fixed and Tokodon was able to build successfully, I worked on adding tests for testing different types of media attachments on statuses, for which I referred to mastodon’s documentation to see what response is received while requesting different kinds of media attachment, which I then integrated into the already present statuses.json file, after which I was successful in displaying different kinds of media attachment.

Once all the different types of media attachments were visible, I expanded the TimelineTest test to include testing of media attachments by asserting whether the different types of media attachments were visible.

The final TimelineTest after implementing the above tasks can be seen in the gif below.

This is a call for people out there to help us test the major version upgrades on Fedora KDE via Discover.

In short: no more Dnf System Upgrade for us!

A bit of context/history: for those of you who follow Nate’s blog you might already know what I am talking about. Thanks to the awesome work done by aleasto on this MR, we closed this bug.

There are, of course, a few quirks to solve but essentially it works.

The @kdesig team has enabled a COPR repository for those who want to help us test the upgrades from F37 to F38.

BIG FAT WARNING: Fedora 38 is still in BETA

I will now explain shorty what are the steps you need to follow to perform the upgrade via Discover:

First enable our COPR:

Now open Discover, go to the Update tab, click on Refresh and eventually on Update All:

Click on Restart Now to trigger the installation of our patched discover

Once you reboot, open Discover again and after a few seconds click on Upgrade to Fedora Linux 38:

Switch to the Update tab and wait until the progress bar finishes. Finally click on Update All:

Now be patient as many packages will need to be downloaded. When it finishes, you will be asked for your password:

Important note: there is a known bug which might trigger an error message at this point. If you see it, don’t panic, just close the message and click on Update All again. This time everything should work.

Time to Reboot, grab a coffee and after a few minutes… you shall boot into Fedora 38!!!

Please try it out and give us feedback on our Matrix room

Looking forward to your feedback!

It’s been a month since my first post about my work as KDE Software Platform Engineer, so let’s have a look at what I have been doing since then.

The scope of what falls under “Software Platform” work is arguably quite wide. I like to describe it as “Taking care of everything needed so that people can build and enjoy awesome software”. Of course that often means hacking on source code, but that is by no means the only thing I do. A significant part of what I do is talking to other people, discussing ideas, reviewing code, making architecture decisions, documenting things, triaging bugreports, and just generally being useful to others. A lot of this work is strategic in nature and the benefits will only show in the long term, but some short-term improvements happend this month also.

My main area of focus was working on polishing the Plasma 6 and Frameworks 6 stability. This means staying on top of things that happen throughout the stack as well as squashing remaining issues. As a result several more projects now have CI builds against the latest development branches of frameworks. Furthermore, I fixed several places where coexistence of Qt5/KF5-based and Qt6/KF6-based software was causing issues.

Qt is an vital part of our software stack, so an important part of being KDE Software Platform Engineer is being involved in its development. Last month I submitted a patch to Qt, fixing a build issues affecting our code. Besides that I have also reported some bugs that were affecting KDE and participated in code review. Another important piece of our stack is our Qt5 Patch Collection that collects bugfix patches for Qt5. I contributed two such patches by backporting them from upstream.

In terms of documentation I have published two blog posts recently. The first explains how to build the development version of Plasma using kdesrc-build. While doing that I have also fixed some related issues in kdesrc-build to make sure building things is as smooth as possible. The second one is explaining some technical details about how theming and platform integration works in Qt/KDE apps. I hope this helps with some of the discussions around this topic that are coming up once in a while.

Besides these “Bigger Picture” topics I have also worked on some concrete enhancements for KDE software. With a series of changes various system windows no longer display an internal and technical application name like “Portal” or “KDE Daemon” in their window title. I have also restored the ability to configure the time interval for determining whether two mouse clicks should be interpreted as a double click. This was present in the legacy mouse settings, but got lost in the transition to libinput. Another thing that got improved was the VPN support in our network settings. When importing a VPN configuration fails Plasma now shows the relevant error message, giving you at least some indication about what’s wrong. Futhermore I fixed a crash when importing VPN configurations when the relevant NetworkManager plugin is missing.

Another area I was working on is our powermanagement settings. Currently they are quite complex, both in terms of UX and implementation. We are working on improving this, which involves quite a bit of technical ground work.

A month from now the Plasma team will meet in Augsburg, Germany for the first in-person Plasma Sprint since 2019. I have been planning and organizing this event. This will be an important opportunity to plan for an awesome Plasma future. However, such meetings are not cheap, so please consider donating to KDE e.V. to support it.

Commit: https://invent.kde.org/qt/qt/qt5/-/commit/4c0d35b0991216766ca301de205599d1daa72057

Commercial release announcement: https://www.qt.io/blog/commercial-lts-qt-5.15.9-released

OpenSource release announcement: https://lists.qt-project.org/pipermail/announce/2023-April/000406.html

As usual I want to personally extend my gratitude to the Commercial users of Qt for beta testing Qt 5.15.9 for the rest of us.

The Commercial Qt 5.15.9 release introduced one bug that have later been fixed. Thanks to that, our Patchset Collection has been able to incorporate the fix for the issue [1] and the Free Software users will never be affected by it! 

Flatpaks are amazing and all that. But application sandboxing, so an application cannot do anything it wants, is a challenge - even more so when you have two applications that need to talk to each other. Perhaps it shouldn’t come as a surprise that native-messaging sandboxing support for Flatpak has been in development for over a year. To celebrate its anniversary I thought I’d write down how to drill a native-messaging sized hole into the sandbox. This enables the use of native messaging even without portal integration, albeit also without sane degrees of sandboxing.

First off, please understand that this undermines the sandbox on a fairly fundamental level. So, don’t do this if you don’t keep your Firefox updated or visit particularly dodgy websites.

For the purposes of this post I’m assuming Firefox and KeePassXC are installed as Flatpaks in user scope.

First order of business is setting up KeePassXC so it writes its definition file in a place where Firefox can read it. Fortunately it has a setting for this:

~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/ is the path inside Firefox’ home where the defintion file will be written. Naturally we’ll also need to adjust the Flatpak permissions so KeePassXC can write to this path.

flatpak override --user --filesystem=~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts org.keepassxc.KeePassXC

At this point Firefox knows about the native messaging host but it won’t be able to run it. Alas. We need some rigging here. The problem is that Firefox can’t simply flatpak run the native messaging host, it needs to spawn a host process (i.e. a process outside its sandbox) to then run the KeePassXC Flatpak and that then runs the NMH.

Fortunately the NMH definition files are fairly straight forward:

{"allowed_extensions":["keepassxc-browser@keepassxc.org"],
"description":"KeePassXC integration with native messaging support",
"name":"org.keepassxc.keepassxc_browser",
"path":"/home/me/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC",
"type":"stdio"}

The problem of course is that we cannot directly use that Flatpak bin but need the extra spawn step in between. What we need is a way to manipulate the definition file such that we can switch in a different path. systemd to the rescue!

systemctl edit --user --full --force keepassxc-native-messaging-mangler.path

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

[Path]
PathChanged=/home/me/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

[Install]
WantedBy=default.target

and the associated service file…

systemctl edit --user --full --force keepassxc-native-messaging-mangler.service

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

[Unit]
Description=keepassxc mangler

[Service]
ExecStart=/home/me/keepassxc-native-messaging-mangler

lastly, enable the path unit.

systemctl --user enable --now keepassxc-native-messaging-mangler.path

Alright, there’s some stuff to unpack here. KeePassXC on startup writes the aforementioned definition file into Firefox’ NMH path. What we do with the help of systemd is monitor the file for changes and whenever it changes we’ll trigger our service, the service runs a mangler to modify the file so we can run another command instead. It’s basically an inotify watch.

Here’s the mangler (~/keepassxc-native-messaging-mangler):

#!/usr/bin/env ruby
# frozen_string_literal: true

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

require 'json'

file = "#{Dir.home}/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json"
blob = JSON.parse(File.read(file))
blob['path'] = "#{Dir.home}/Downloads/keepassxc"
File.write(file, JSON.generate(blob))

It simply replaces the path of the executable with a wrapper script. Here’s the wrapper script (~/Downloads/keepassxc):

#!/bin/sh

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>

exec /usr/bin/flatpak-spawn --host --watch-bus "$HOME/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC" "$@"

flatpak-spawn is a special command that allows us to spawn processes outside the sandbox. To gain access we’ll have to allow Firefox to talk with the org.freedesktop.Flatpak DBus session service.

flatpak override --user --talk-name=org.freedesktop.Flatpak org.mozilla.firefox

And that’s it!

➡️ KeePassXC writes its NMH definition to Flatpak specific path ➡️ systemd acts on changes and starts mangler ➡️ mangler changes the path inside the definition to our wrapper ➡️ Firefox reads the definition and calls our wrapper ➡️ wrapper flatpak-spawns KeePassXC flatpak ➡️ Firefox (flatpak) talks to KeePassXC (flatpak)

Buttons are a fundamental element in user interfaces, but it’s easy to make some accessibility mistakes when using icon-only buttons in QML.

First, please avoid icon-only buttons and only use then, when the icon is very well known (e.g. arrows, delete or favorite icons) and the space is limited.

In case you still want to use an icon-only button. Make sure to set the text: property and that it is also translatable. Otherwise, a screen reader won’t know that to say about the button. This is because the text: property is used as default value for the Accessible.name: property, so when it is not set Accessible.name is empty and the screen reader can only say that the currently focused control is a button. The trick to have both the text: property set and an icon-only button is to use the display: property and assign it to the AbstractButton.IconOnly.

This gives us the following code:

import QtQuick 2.15
import QtQuick.Controls 2.15

Button {
 text: i18n("Favorite")
 icon.name: 'favorite'
 display: AbstractButton.IconOnly
}

Finally, another essential part is that an icon-only button requires a tooltip. We need the tooltip in case the user is unsure about the meaning of the icon and we need more details.

import QtQuick 2.15
import QtQuick.Controls 2.15

Button {
 text: i18n("Favorite")
 icon.name: 'favorite'
 display: AbstractButton.IconOnly

 ToolTip.text: text
 ToolTip.delay: Kirigami.Units.toolTipDelay
 ToolTip.visible: hovered
}

Note that this used the ToolTip attached property instead of a separate item ToolTip {} as it is more memory efficient. With the attached property, we share the tooltip instance across the entire application instead of instanciating a ToolTip popup for each button.

Another month in the year, another collection of bugfixes and features I contributed to KDE!

Documentation Improvements

Something I want to improve for KDE Frameworks 6 is the API documentation, it’s pretty bad sometimes:

[Bugfix] For plasma-framework, we started marking private QML types as internal. I’m in the process of manually fixing up the custom QQuickItem types in plasma-framework too, although I haven’t gotten around to opening up a merge request for that.

[Feature] I opened a doxyqml¹ merge request to make it’s output more useful, by automatically adding import statement hints to the page:

Plasma 6 Porting

[Feature] Early this month, I ended up porting most of our applets to Plasma 6! The current hitlist is:

• Sticky Notes
• Binary Clock
• Color Picker
• Fuzzy Clock
• Web Browser
• Konsole Profiles
• Media Frame
• Quick Launch
• Quick Share
• Timer
• Input Method
• Activity Manager
• Kicker

The two I’m still working on and need further testing and reviewing:

• Comic
• Kate Sessions
• Disk Quota (if you have disk quotas, please help me test this one!)

I also fixed activity switching, and fixed KRunner’s broken layout.

For those who are building Plasma 6 for the first time, extragear modules are now built by default!

PlasmaTube

[Feature] I started using PlasmaTube which is KDE’s Youtube Client, to replace FreeTube. I started by cleaning up and overhauling the account management, so it flows better.

[Bugfix] I also made the info chips non-interactable, fixed the spacing on video grid text, added more loading placeholders and stop desktop users from being able to drag the video page.

Ruqola

[Feature] Because of $work, I discovered that we have a Rocket.chat client! I miss being able to quickly switch my presence via the tray icon, so that’s the first thing I opened a merge request for.

Dr. Konqi

[Feature] Someone pointed out that the margins in the bug reporting wizard was terrible, so I started a redesign of the whole UI trying to update it to look similar to our modern applications:

Tokodon

In preparation for the 23.04 gear release, I added a slew of new features and bugfixes!

• [Bugfix] The Status Composer is now automatically focused, and you can press CTRL+Enter or CTRL+Return to submit.
• [Feature] You can now check, allow and deny follow requests.
• [Feature] When replying to a post, the post now shows up inline in the composer!

• [Feature] There are now way more notification filter types, not just “All” and “Mentions”.

And of course, there are of course many bugfixes:

• [Bugfix] Account strings that are just “@” are now detected and handled properly, so it doesn’t get stuck.
• [Feature] When searching, it’s clearer for slower connections that the list is temporarily empty because it’s loading.
• [Bugfix] Don’t allow users to edit the visibility of existing posts, which doesn’t work.

[Feature] As a treat for people who manage popular accounts - like our great KDE and Krita promo teams - I have a work-in-progress merge request to allow you to group notifications! I expect to find time next month to finish and polish this feature, but no promises yet.

Miscellaneous

• [Bugfix] Finished Nate’s work on hiding separators when the kickoff is sorted alphabetically, this will land in 5.27!
• [Feature] Added a unit test to Kalendar.

I’m happy to announce KTechLab release version 0.51.0. KTechLab is an IDE for microcontrollers and electronics. This new release contains the following changes:

• updated and improved translations
• the Serial Port component, for better compatibility, uses Qt’s QSerialPort, instead of operating-system specific library calls
• experimental support for Windows; it requires MSVC 2019 compiler
• various stability fixes
• modernisation of the codebase, porting away from some deprecated APIs

The release tarball of version 0.51.0 can be downloaded from KDE servers. Its checksums are:

SHA256Sum: 046b9ce1f2c2a93e1da734a416674a5bb5da3203ac773d49ed693b8492f6d212
SHA1Sum: 7729b67050caee5b65fe4dd1dfbfce213cea44ac
MD5Sum: 2853c6867535995c1ead598e98fce6e3

Useful links related to KTechLab

KTechLab has a mailing list at KDE called ktechlab-devel: https://mail.kde.org/mailman/listinfo/ktechlab-devel

On IRC, developers are mostly reachable on freenode.net, on #ktechlab channel.

The source code of KTechLab is available in KDE Git, at https://invent.kde.org/sdk/ktechlab

Instructions for building and running KTechLab are available in the README file from the source code; online version of that file is available at https://invent.kde.org/sdk/ktechlab/-/blob/master/README ; The very short instructions are: run sh build-simple.sh and then sh run-simple.sh.

The notes from joining KDE: https://community.kde.org/Incubator/Projects/KTechLab

KTechLab bugs at KDE bugtracker: https://bugs.kde.org/buglist.cgi?quicksearch=ktechlab