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.

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

We're happy to announce the new release 5.10.0 of KPhotoAlbum, the KDE photo management program!

The ChangeLog for this version is as follows:

Changed

• View-related actions formerly found in the "Settings" menu were moved to the "View" menu.
• Make options "Display Labels in Thumbnail View" and "Display Categories in Thumbnail View" reachable via the "View" menu and allow both actions to be assigned keyboard shortcuts (Implements: #145346).
• Store the untagged tag information inside the index.xml file instead of the Settings (Implements: #461206).
• Change scroll direction in the annotation dialog's date edit fields to match common (western) expectations and the date picker.
• Prevent scrolling past the occupied areas of the date bar.
• Files are now always created with group read/write permissions (Fixes: #438128).
• When exiting the demo mode, the demo database is now always saved if it isn't deleted.

Dependencies

• CMake: 3.18
• Qt5: 5.15
• KDE Frameworks: 5.78

Fixed

• Improve readability of "Show Tooltips in Thumbnails Window" tooltip.
• Fix image selection order for newly added images (Fixes: 442325).
• Improve date bar behavior when zooming the date bar and changing views (Fixes: 357237).

Removed

• Default shortcut for "View" images was removed.
  Pressing "Enter" to open the viewer is now the preferred way. To restore the old behavior, reassign the shortcut via "Settings | Configure Keyboard Shortcuts...".

Thanks to everybody having contributed to this release! The authors were (according to git log and in alphabetical order):

• Christophe Giboudeaux
• Tobias Leupold
• Luigi Toscano
• Johannes Zarl-Zierl

Have a lot of fun with the new version!

— Tobias

As you probably have heard by now the lastest development versions of Plasma and KDE Frameworks require Qt6. This transition has been in the works for a few years by now, but it was only somewhat recently that we took the plunge and started relying on Qt6 exclusively for Plasma. Plasma 5.27 is the last Plasma 5 release and continues in bugfix-only mode.

For people who want to hack on Plasma features this raises the obvious question: How do I build Plasma 6 to hack on it?

Before diving into this, a word of warning: Current Plasma master is in no way “ready for production”. There are known-broken things and things may temporarily regress at any time. That said, the only way to get towards a stable thing is to dig in and fix things. So let’s see how to do that.

For this explanation I’m assuming you have build KDE software with kdesrc-build before. If not we have some extensive documentation for that. First you need at least Qt 6.4 installed. The usually best way to get that is from your distribution. If your distribution does not have Qt6 packaged yet please complain^Wtalk to them. CMake should complain about any missing Qt6 modules/development files, but make sure you have the qtpaths tool installed beforehand. It should be named something like qtpaths6 or qtpaths-qt6.

Now we need to teach kdesrc-build to build Plasma with the right configuration (git branches, CMake arguments etc) for building with Qt6. The easiest way to do that is by using a separate kdesrc-buildrc file. kdesrc-build comes with a sample Qt6 configuration file that you should use as a starting point. Replace the line include ~/kde6/usr/share/kdesrc-build/kf6-qt6-build-include with a path to your existing kdesrc-build installation. For me that would be include ~/kde/src/kdesrc-build/kf6-qt6-build-include. You can also apply other customizations that you usually do in your kdesrc-buildrc. Then save the file as e.g. ~/kde6/kdesrc-buildrc. This configuration will download, build, and install everything under ~/kde6. Currently it is very important to keep Qt5-based and Qt6-based builds separate since there will be conflicts between the installed files.

Now you can invoke kdesrc-build as usual, with one slight difference. Passing --rc-file=/home/user/kde6/kdesrc-buildrc will make it use the Qt6 configuration. If you omit the --rc-file argument it will use the old, Qt5-based configuration, so you can keep building Qt5- and Qt6-based stuff in parallel (but installed into different locations). Since kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc is a bit of a mouthful you might want to configure a shell alias like kdesrc-build6 for it.

Now you can do kdesrc-build --rc-file=/home/user/kde6/kdesrc-buildrc workspace to build Plasma. Note that it’s expected that not all modules successfully build since not all of them are adjusted to Qt6 fully yet.

Once Plasma is build you want to log into the new session. To do that go to ~/kde6/build/plasma-workspace and run sudo ./login-sessions/install-sessions.sh once. Then you can select the new session at login in SDDM.

Now for some question that might be on your mind:

Q: Is it stable?

A: No, see above.

Q: When will it be stable?

A: Time will tell. It will be several more months before we can consider a Plasma 6 release.

Q: I tested it and found a problem, what should I do?

A: Report it to bugs.kde.org, and state that you are using Plasma master. Or try fixing it yourself.

Q: I want to work on a Plasma feature, what should I do?

A: Try developing it against Plasma master. If you find yourself blocked by anything please tell us.

Q: Does this apply to other KDE software as well?

A: Yes. Note that most applications allow building against Qt5 and Qt6 from the same branch though. And some apps aren’t ported to Qt6 at all.

Q: I did not understand a word of what you just said but I’d still like to help.

A: One way to help is by donating to KDE. Your donations help me have time to do things like working on Qt6 support or writing this blog post