Unfortunately C++ makes it rather easy to leak memory. Fortunately we have tools to find such leaks. One such tool is Leak Sanitizer (LSAN) from the Address Sanitizer (ASAN) family. It’s using compiler-based instrumentation for the code to reports any leaks after the program terminates.

KDE’s CI infrastructed has ASAN enabled for a while. However the leak sanitizer part was explicitly disabled, so no leaks were reported as part of the CI build and test run. This is because a number of projects have pre-exisiting memory leaks that would cause the C build to fail. Of course those should be fixed eventually, but in order to do that we need to know where they are. Also, for projects that currently don’t have any leaks we want to enforce keeping it that way.

A few lines of Python later KDE’s CI system now allows to enable LSAN on a per-project basis. The .kde-ci.yml file that governs CI builds in KDE gained a new option enable-lsan. It is off by default for now for compatibility, but we may consider enabling it by default eventually.

If enabled and any memory leak in a test is detected, that test and therefore the whole CI pipeline will fail.

Now once we found a leak, what can we do about it? There’s several options:

• Use good old delete/free(). Works, but is often rather error-prone.
• Use QObject’s parent mechanism. Works, but often frowned upon by C++ purists. Mostly makes sense for widget hierarchies.
• Smart pointers like std::unique_ptr/std::shared_ptr. These are great because they allow to express the ownership on an API level and make ownership transfers explicit. Often the best choice for business logic code.

LSAN is now enabled for some Frameworks CI builds, but ideally it would be enabled for all KDE projects. And of course any leaks found along the way should be fixed.

Happy leak-fixing!

The number of services available and applications making use of them changed a bit over recent years. As of right now the following services are supported:

• Nextcloud: This is used by Dolphin to add a shortcut for file access via webdav to the Network section, as well as the Purpose framework to allow uploading files to Nextcloud.
• Owncloud: Used for the same things as Nextcloud.
• Google: Used by Purpose for uploading to YouTube. In theory also used by kio-gdrive for browsing Google Drive, but access to this is currently blocked by Google.
• OpenDesktop: Used for reviewing store.kde.org content in Discover

This isn’t all that much. Notably absent here is KDE PIM, which could greatly benefit from integrating with the Nextcloud and Google accounts. This is something many users have asked for over time. Plus, there’s more services that are used across applications and could benefit from a systemwide online accounts system, like Mastodon or Matrix.

Overall the situation with online accounts support in KDE is unsatisfactory, and it’s not for a lack of trying. Over the last few years there have been several smaller improvements to the system. However there have been no changes to the overall architecture. At this point I am convinced that the architecture is what’s holding us back, and we need to do something about that.

The current system is based on the Accounts SSO framework. It consists of several libraries and processes, split across about a dozen different repositories. This makes for a rather complex system for what is effectively reading and writing to a sqlite database and some OAuth handling. It also receives very little development activity, to the point where it was hard to get the required patches for Qt6 support in. Using an external accounts system as based for KAccounts only makes it harder to iterate on our system, while providing no meaningful interoperability with other parties.

The system also isn’t designed for a sandboxed world. Apps have direct access to the accounts database and keychain, so there is no ability to restrict which apps can use which accounts. While per-application access control wasn’t really feasible for traditional Linux packaging, with sandboxed formats like Flatpak we can and want to restrict apps to only be able to access select accounts.

Having pondered the problem for a while I came to the conclusion that we need a fresh start for our online accounts story, a new system that fullfils the following goals:

• It’s actually used by relevant KDE and third-party software
• Easy to hack on and extend
• Easy to be integrated into consumer software, with minimal dependencies
• Can be extended with third-party providers
• Account data is stored reasonably securely, with per-application access control (for sandboxed applications at least)

Based on these goals I have developed a prototype for how such a system could look like.

At its core there is a daemon process that manages the accounts, and exposes them via a DBus interface. Applications uses this DBus interface to list availble accounts as well as their parameters and credentials. Only accounts the app has been granted access to are visible that way. Application authentication works in a way that’s inspired by how xdg-desktop-portal works.

An application can trigger a request for accessing a new account. The dameon will then handle the whole login flow and, if successful, will return a handle to the new account. Alternatively the user can log into a given service in the systemsettings module and give access to relevant apps though that.

Currently the following services/apps are supported:

• Nextcloud: Used by Purpose and KDE PIM
• Mastodon: Used by Tokodon
• Google: Used by KDE PIM and Purpose

You can find the code at https://invent.kde.org/nicolasfella/konlineaccounts.

It is still very much a prototype, which is by no means ready for production, but it shows the basic concept. If you have input on this please get in touch, for example by filing an issue.

They relate to graphics tablet/stylus input on Wayland. Before we go into the fixes let’s have a quick overview of the flow of tablet input events on Wayland:

The genesis of input events is in the kernel driver for the particular tablet, which talks to the hardware (via USB, bluetooth etc). The kernel passes events to userspace via the evdev system. On the userspace side a Wayland compositor reads those events. Most compositors leverage libinput for this, a library that transforms raw evdev events into something more usable for the compositor while applying some cleaning and configuration. The compositor then delivers events to native Wayland applications using the tablet-v2 protocol. For legacy XWayland applications the compositor uses this protocol to send events to XWayland, which translates them into things X11 apps understand. The compositor can apply useful transformations to the input, like which area of the screen the tablet is mapped to, changing the pressure curve of the pen, or binding buttons to keyboard shortcuts.

The application then processes the events, potentially leveraging a UI toolkit like Qt. Qt creates QTabletEvent object for incoming Wayland events and delivers those to all UI elements. In case no UI element reacts to the event Qt will synthesize a mouse event from the tablet event and deliver that to the UI elements. That way most controls like buttons and menus don’t need special code to handle tablet input. Only when doing very low-level input handling or when needing tablet-specific interactions (like reacting to different pressure values) application developers need to explicitly handle tablet events in their code. Most UI toolkits will work somewhat similar to this. If an application doesn’t react to tablet input at all please file a bug against the application.

Qt Wayland had support for tablet input for a few years now, so what exactly needed fixing? The first thing is cursors. In Wayland the application tells the compositor which cursor to use. This can be done either by specifying a surface (i.e. an image) or a named cursor shape. Guess which one Qt used? That’s right: Neither. It just didn’t specify a cursor at all. The result depends on the compositor: KWin would display a cross-hair cursor as a fallback, which is ~okay, but not the cursor the application developer asked for. On other compositors I’ve tested there will be no cursor visible at all, which isn’t okay at all. For Qt 6.8 I implemented the missing cursor support, so now tablets get the same cursor as mouse input (unless of course the application developer wants a different cursor for tablet input).

Another thing that affected mostly non-Plasma users is client-side decorated windows. On Plasma Qt applications usually use the server-side decoration provided by KWin, but e.g. on GNOME Qt is responsible for drawing and handling window decorations. For this Qt features a plugin system so different decorations with different look-and-feels can be swapped out. Unfortunately those decorations didn’t handle tablet input at all, so it wasn’t possible to move around or close windows using a tablet stylus. I fixed this by pretending the tablet input is mouse input to the decorations, which was a simple yet effective solution for the issue. If there is ever a need for decorations to treat tablet input different to mouse input we can revisit this.

Talking about moving windows, a feature most KDE apps have (even if off-by-default these days) is dragging any empty area to move the window. This wasn’t working when using a stylus. Why? For that we need to look at how this works on a Wayland level. The xdg-shell protocol (the one responsible for most application windows) has a move request that asks the compositor to start a move interaction for the window. As part of the request the application must pass a serial, which is a number that corresponds to the last input event the application has received. To avoid applications suddenly deciding to move in the background compositors usually only allow move requests as a result of direct user input, so this serial must match the last input event. Qt wraps this move request inside the QWindow::startSystemMove function. The problem was that Qt didn’t keep track of the serial it received as part of tablet input, so when starting the move it would pass a wrong serial and the compositor (rightfully) refused the move. A few extra lines later the serial was tracked properly and moving windows with a stylus worked, just in time for Nate to disable the feature by default.

The same problem also affected drag-and-drop. When starting a drag with a stylus Qt now passes the correct serial, making drag-and-drop work (at least on the Qt side, there currently is a bug on the KWin side that prevents this from working).

The last fix for today relates to how applications react to the tablet events. Sometimes applications process clicks differently depending on what keyboard modifiers are pressed. For example pressing Ctrl while clicking on files in Dolphin allows to select multiple files. For this to work Qt conveniently delivers the active modifiers with every input event. Alas for tablet input the modifiers got lost along the way, so it wasn’t possible to select multiple files using a stylus. One small fix later it works as expected.

That’s all the Wayland tablet related fixes for today. If you find more issues in Qt/KDE apps related to tablet input on Wayland please report them on bugs.kde.org and I’ll look into them.

That’s not all there is about Wayland tablet improvements though. Fully in the spirit of the “We care about your input!” Goal there are exiting things happening on the KWin/Plasma side that I’ve been involved in. Stay tuned for more!

In my position of Software Platform Engineer at KDE I work on common building blocks for KDE software, like Qt and KDE Frameworks. This work is possible thanks to your generous donations. Check out our end-of-the-year fundraiser if you’d like to see more work like this.

First of all, instead of me travelling to Akademy it took place in my hometown of Würzburg, Germany. While I did have a hand in organizing it, most of the credit for it goes to Tobias and David. I had a lot of fun introducing people to my area and the concept of drinking wine on a bridge.

Qt Contributor Summit

Right before Akademy there was the Qt Contributor Summit, also in Würzburg (what a coincidence!). It was great to meet old and new Qt faces and talk about topics that are relevant to KDE, like the upcoming migration of KDE API documentation to qdoc.

Akademy Talks

This Akademy I gave two talks: One long one where I looked back at the Qt6/KF6 transition, what went well, what didn’t, and looked towards the future of what’s next for our software platform. Then I also had a lightning talk where I talked about the role of maintainers in open-source projects, why KDE doesn’t have traditional maintainers, and why that’s a good thing.

Besides that there were also a lot of interesting talks from other people, too many to mention right now. Speaking as a member of the program committee we had some tough decisions to make about what to include.

Goals

During the conference we announced the new set of Goals that were recently elected. I’m excited that my own proposal “Streamlined Application Development Experience” got selected and I’m looking forward to working on it with you. Besides that I also want to see how I can help out with the other elected goals: “We care about your input” and “KDE needs you 🫵”.

Akademy Awards

Another way this Akademy was special for me is that I was awarded with an Akademy award for my work on KDE Frameworks and Plasma. It feels great to get recognition for all the work I’ve been doing for the last seven years.

BOFs

During the week we had lots of smaller meetings and workshops (a.k.a BOFs, world’s most terrible acronym). I was leading two of them, one about my newly-elected goal where I was presenting my proposal in more detail, and one about the ongoing work of mine to migrate our API documentation to qdoc. Thanks to our sysadmin Ben we now have a website where the current (still very much WIP) state of the new API documentation page can be seen.

Other Things

What’s great about Akademy isn’t just talks and BOFs, it’s meeting people you only see online all year, talking to them in person, getting your code reviewed while staring on a screen together, chatting over random visions, complaining about things, laughing and enjoying things together, and wrapping up the day with a nice beer in your hand.

I’m already looking forward to next year’s Akademy, wherever that will be. Maybe it will be your place, organizing it is a lot less scary than you’d think ;).

I mentioned that when using Kate qmlls should work out of the box when opening a QML file. That’s mostly true, there is one problem though. Depending on your distribution the binary for qmlls has a different name. Sometimes it’s qmlls, sometimes qmlls6 or qmlls-qt6. You may need to adjust the LSP Server settings in Kate to match the name on your system.

In order for qmlls to find types that are defined in your application’s C++ code those must not only be declaratively registered, qmlls also needs to be told where to find the type information. Fortunately Qt 6.7 comes with a handy way to do that. By passing -DQT_QML_GENERATE_QMLLS_INI=ON to CMake you get an appropriate config file generated. This will be placed into the project’s source directory but is specific to your setup, so add that to your gitignore file (PS: You can set up a global gitignore file for your system, so you don’t need to add this to all your projects). Unfortunately the initial implementation produced wrong configurations for some modules, but this is fixed in Qt 6.7.2.

A problem I mentioned is that qmlls doesn’t find modules that are not installed into the same path as Qt. With Qt 6.8 there will be two new options. The -I parameter allows to add custom import paths to qmlls’ search paths. The -E parameter makes qmlls consider the value of the QML_IMPORT_PATH environment variable for its search paths.

In order for qmlls to work properly modules need to be created using the CMake API and use declarative type registration. Since writing the last post some KDE modules have been converted to those, but there’s still more to do.

Thanks to the QML team for those swift improvements!

Being interested in all three goals made it a bit callenging to follow all relevant discussions unfortunately, but on the flip side it never got boring.

Most of my goal-related work was towards the automation goal. One thing I was working on is a CI job that checks for spelling mistakes in the code, so that those can be caught when doing a MR. A while ago I create a website that tracks which KDE projects are ported to Qt6. What started out as a joke for a talk turned out to be a useful tool for planning porting work. During the print I fixed the site to actually work correctly again and, most importantly, changed the text from “No” to “Yes” since most projects actually use Qt6 now. For a while the site also has auto-generated reports for other things, like showing which projects don’t yet have clang-format applied to them or which projects don’t enforce passing test in the CI. I used the latter list to enable this for the remaining projects that don’t have failing tests right now and prepared a change to the CI system that enforces passing tests by default. In the same spirit others and I also fixed some currently failing tests. We also discussed the idea of extending the site with more checks and turning it into a proper KDE site that isn’t hosted on my personal infrastructure.

Harald, Carl, and I worked on a dashboard to show the CI status for our project. This is something we haven’t really had since switching to Gitlab CI but is very useful e.g. as part of the release checklist. We do have a working prototype, but some things remain to be ironed out. As part of this we also fixed some of the currently failing builds.

My main contribution to the systainability goal was debugging why Nate’s NeoChat is using too much CPU. With a team effort we eventually pinpointed this to an invisible animation constantly repainting the window, which was then promptly fixed.

In terms of accessibility I was mainly involved in discussions about challenges and new developments with accessibility on Wayland. Expect to hear more on this soon.

In “off-topic” topics there were plently of discussions about visions, ideas, and challenges for our application development story. This included discussions on visions for design/UX, theming, API design, and software distribution. Being KDE’s Software Platform Engineer it is part of my responsibilities to facilitate these kinds of discussions. Later this year I want to host a sprint dedicated to application design to discuss and establish our vision there. If you are interested do reach out to me.

All in all it was a fun few days with great people. Thanks to MBition and Aleix for hosting us, and thanks to those donating to KDE to make these sprints possible.

Naturally many people are eager to use it to hack on KDE code. When trying to do that you probably have encountered some frustration with things not working as expected. So what’s going on there, and how can we make it work?

First and foremost one must mention that qmlls is still under heavy development. There’s a number of things missing that you’d expect from a fully featured LSP implementation. If you encounter something that looks like it should work but doesn’t, don’t hesitate to file a bugreport.

So how does one use qmlls? In Kate it should be activated out-of-the-box when opening a QML file. If that doesn’t work you might need to tweak the LSP-Client settings. For other editor please consult their documentation on how to enable LSP support.

One problem you are likely to encounter when using qmlls on KDE code is that it fails to find KDE-provided QML modules like Kirigami. This happens when the modules are installed into e.g. ~/kde/usr, which isn’t searched by Qt. One way to get around this is to build and install your own Qt into ~/kde/usr too, since that way the modules will be installed into the same prefix as Qt and Qt will find them. While building your own Qt is a worthwile thing to do in general it’s not a very satisfying solution. I hope we can find a better solution for this soon. See here for a related bugreport.

If your installation is set up in a way that qmlls can find the KDE-provided modules you might still encounter it warning on unknown modules or types. In order for qmlls to show information for a module the module needs a qmltypes file. These files provide machine-readable information about the types that the module exposes. The easiest way to make these available is porting the module to ecm_add_qml_module and declarative type registration. This was done for many KDE modules already, but there’s still a number of them missing. Help on that is very welcome! Something that isn’t obvious is that in order for the tooling to work correctly module dependencies need to be marked explicity via the DEPENDENCIES parameter in ecm_add_qml_module.

If all the modules and types are found correctly you will still encounter some warnings, but most of these should correspond to actual issues and non-optimal practices like using unqualified property lookups and context properties. qmlls is a great tool to guide you towards resolving those and thus modernizing and optimizing the code. There are however some classes of warnings for which we don’t have proper solutions yet:

• Our translation functions, i18n and friends, are considered unqualified lookups by qmllint/qmlls. This is because they are magically injected into the engine at runtime. It’s not clear how a solution for this could look like.
• When writing KCMs we expose the module’s C++ class via the kcm context property, which is opaque to the tools. A different approach is needed.

Despite the current limitations qmlls is already a very useful tool for working on QML code, assuming the project is set up properly.

Happy QML hacking!

If you are reading this from the future there’s an update available.

However there is one aspect that makes it less attractive for third-party developers: It’s number of dependencies. As of KNotifications 5.110 it depends on the following other KDE Frameworks:

• KCoreAddons
• KConfig
• KWindowSystem

as well as some third-party like QtWidgets, X11, libdbusmenu-qt and libcanberra.

While none of these are a hard blocker for usage in most cases the overall impression isn’t very appetizing. During the KF5 time we already weeded out some dependencies that don’t make sense on some platforms, like removing the QtWidgets dependency on Android. We were however somewhat limited in our ability to do large cleanups by our strict API/ABI stability promise. For KF6 we have the opportunity do to larger cleanups.

One larger source of dependencies is the KStatusNotifierItem class, which is part of the KNotifications framework and is used to create system tray icons. Since its functionality is rather independent from creating popup notifications we decided to split it out into a separate, new framework. This significantly reduces the number of dependencies of KNotifications. A number of other changes further reduced the number of dependencies and cleaned up the public API a bit.

As a result what will become KF6 KNotifications on Linux only depends on Qt (QtGui + QtDBus, and optionally QtQml for QML support), KConfig (that would also be feasible to remove if someone is motivated enough) and libcanberra (for playing notification sounds).

Other KDE Frameworks received similar changes, but KNotifications is likely the one where this has the largest impact.

Doing this kind of work is part of my position as KDE Software Platform Engineer. To support my work please consider donating to KDE e.V..

Other people have already well summarized what happend there, so let’s have a look at what I have been doing:

Together with Kai Uwe, Volker, and Ismael I looked at notifications. This includes internal simplifications in KNotifications, API design questions, a proposed V2 for the notification portal API, and a new UI for per-event configuration in the notification settings module.

Together with Marco I looked into some API design topics around the Applet class in plasma-framework, and worked on a proposed new API for applet actions.

Given that Wayland was a huge topic at the sprint I continued the work of mine on enabling some accessibility options on Wayland. Sticky keys is not only what happens when you spill Spezi over your laptop, it is also an accessibility feature that allows people that cannot press multiple keys simultaneously to type key combinations like Control+C/Control+V. Basic support for this on Wayland is coming with Plasma 6. Not all of the options that are present on X11 work yet though. If you are a user of sticky keys please leave your feedback on https://bugs.kde.org/show_bug.cgi?id=444335 for which of these options should be prioritized.

Together with Natalie, KDE e.V.’s Hardware Integration Engineer, I discussed our touchpad configuration module and how to make it more robust and maintainable. We also discussed various topics around debugging and profiling KDE software.

Together with Xaver I looked into how Dolphin/KIO handles multi-GPU setups (so that apps preferring discrete GPUs will use them when launched via KIO). As it turns out there’s a few things to be improved there so we discussed approaches to do that.

With David I discussed some of my open changes to our global shortcuts infrastructure and continued working on improving that.

We also got a visit from two people from the city of Treuchtlingen, Germany. They have been using KDE software in their communal IT for over 20 years. We discussed their vision of using open source and open standards in government IT and some of their pain points with using KDE software for that.

Overall it was a very nice and productive week and it was great to meet so many fellow KDE hackers, some of them for the first time! Gatherings like this are only possible because of generous donations to KDE e.V. Please consider donating to make more such sprints possible.

As usual not everything I did ended up as committed code. A lot of my work is reviewing other people’s code, discussing ideas, and generally being useful to the community.

One area I’ve been focussing on is our infrastructure for global shortcuts. These are currently handled by the KGlobalAccel framework. This frameworks contains the runtime component that manages global shortcuts as well as an application-facing library to interact with the runtime. The runtime and interface library being in the same project has caused us some issues in the past. To address these the runtime part is now split out into a separate project and part of the Plasma group. You can read up more details on this here. This change also allowed for some further changes that made launching applications from global shortcuts both simpler code-wise and more robust. I have also worked on another set of changes that will address some of the pain points that are currently present in our global shortcuts system. While doing that I also addressed some issues I found in the underlying KDE Frameworks libraries.

Another area I worked on is notifications. One thing I did there was reducing the API surface of the KNotification class by hiding internal API that shouldn’t be exposed to application developers. I also proposed a revamped API for specifying notification actions. The new API is both easier to use for application developers and easier to extend with new features in the future.

With a small API change to KStatusNotifierItem, our class for implementing system tray icons, it is now easier for QML applications to fully make use of its capabilities. The API to set an associated window previously was only really usable for QtWidgets apps, now it can be used for QML apps too.

In some Plasma news: Plasma now uses the C++20 standard. This allows us to use some nifty new C++ features. One big one that comes to mind are coroutines, which have the potential to massively simplify parts of our code. Getting there required some tweaks to make our code and our dependencies fully C++20-compliant.

Talking about dependencies: With our move to Qt6 all of our Qt-based dependencies need to make that move too. appstream-qt, the library that powers e.g. Discover is now ready for that too. I helped integrating that into our build infrastructure. Another project with such dependencies is our online accounts system. It depends on libraries like libaccounts-qt and signond, which I’m working on porting to Qt6.

Last weekend I attended the Linux App Summit in Brno, Czech Republic. It was a lovely event that allowed me to get in touch with both people from KDE and our partner organizations like GNOME and Flathub.

To support the work I and many other people do in KDE please consider donating to KDE e.V. Your donations make my work as KDE Software Platform Engineer possible. Thank you for that!

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.

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

During this discussion I noticed two major disconnects between the involved parties. One of them is technical in nature, where (understandably) not everyone involved has deep knowledge about how Qt and KDE apps work. The other one is cultural in nature, where there’s opposing views about who gets to decide how an application should look and feel like on a given platform.

I can’t do much about the cultural issue, but I can help the conversation by giving some much needed overview of how any of this works on a technical level. Everyone being on the same page technically could help foster a more productive conversation about this complex topic.

First of all it’s important to note that Qt to its core is an abstraction across various plaforms (most important here are Linux, Windows, and macOS, but also to some degree Android and iOS). Whenever possible Qt tries to use the platform’s native facilities to do anything, whether that’s rendering, file dialogs, widget styles etc. This becomes somewhat messy when you consider that “Linux” isn’t exactly a single, well-defined “platform”. Qt does usually have non-native fallbacks for things like file dialogs and widget styles, but they aren’t necessarily something you want a user to have to see. It’s also important to mention that Qt has two somewhat competing ways of defining UIs, the traditional QtWidgets, and the more recent QtQuick/QML.

There are several somewhat independent pieces involved in how a Qt application looks and feels. Jan Grulich already talked about some of them in the context of GNOME and QGnomePlatform, but there are also things specific to KDE applications that aren’t mentioned.

The first piece is the “Qt Platform Theme (QPT)”. Despite the name it doesn’t have much to do with the visual style. It is responsible for applying settings from the platforms. This for example includes font settings, the double click interval, or whether a file should be openend on single or double click. It also defines how standard dialogs look like, most importantly the file picker dialog, but also dialogs like a color picker. Third, it defines the color palette (QPalette) the application is using. More on that later. Qt itself ships platform themes for non-Linux platforms as well as somewhat generic Linux platform themes for GNOME and Plasma. Notable out-of-tree plugin exist, like plasma-integration which you are using right now if you are on Plasma, the aforementioned QGnomePlatform targeted towards GNOME (and to some degree similar environments), and qt5ct, which isn’t aligned to a specific environment and provides generic control over platformtheme things.

The second, and perhaps most well-known, knob is the widgets style (also called QStyle). It controls the majority of the appearance of a QtWidgets application. Well-known examples include Breeze (the current Plasma default), Oxygen (the KDE4-default), adwaita-qt, as well as built-in styles for Windows/macOS. Qt also comes with a built-in Fusion style. QStyles are implemented using C++ plugins. Whenever the app needs to render some piece of UI, e.g. a button, it defers that to the style plugin. Some style, like e.g. Windows then use platform native APIs to render widgets, others like Breeze draw the widgets from scratch. Application developers can also include custom styles for complete control over the appearance.

The third important concept is QPalette. A QPalette is a set of colors used to draw UI elements. The palette is defined by the platform theme(!). For example Plasma uses this to apply the color scheme set in System Settings. QGnomePlatform uses it to apply Adwaita-like colors. The selected QStyle may (or may not!) use this palette when drawing controls. The application developer can also manually query colors from the palette for drawing custom widgets while still respecting the platform’s wanted colors. A platform theme may only offer a single palette this way, or include light and dark variants, or allow the user to configure arbitrary color sets (like we do on Plasma). It is also possible for application developers to override the system-provided palette, for example to offer an in-app dark mode switch.

For applications using QML there is another relevant component: The Qt Quick Controls 2 Style. For reasons I’m not going to go into QtQuick Controls don’t use QStyle for their styling. Instead they come with their own stying system, which is itself based on QML. In Qt5 QML apps only have a very basic and broken default theme that should never be used. In Qt6 they use Fusion by default.

These are the relevant knobs every Qt app has. Some app developers choose to use them to control the appearance of their apps themselves, but many others leave it to the environment to apply a suitable look and feel. Furthermore, there are some relevant KDE-additions to this that are important to understand.

One such addition is KColorScheme. You can think of KColorScheme as a superset of QPalette, i.e. it provides additonal color roles and thus finer-grained control over colors. When changing the Colors setting in Plasma’s System Settings you are picking a color scheme. This gets applied to QPalette via the plasma-integration QPT, but can also be queried directly by the application developer for custom painting. Contrary to QPalette a KColorScheme is not porgrammatically filled based on plaform values (that happens only on Plasma), but it is a static, textual list of colors. Here we have the first problem for running KDE applications under e.g. GNOME. When running a KDE app on GNOME QGnomePlatform will apply Adwaita colors using QPalette. However, this does not affect colors the application directly pulls from KColorScheme, which unless explicitly configured has a default that resembles Breeze. This means we get mixtures of two different color sets, giving unpleasant results. This is especially noticeable when using a dark system theme combined with the light default colors from KColorScheme.

How do we solve this? Well, I’ve been banging my head against that problem for a while. Short of removing the concept of KColorScheme entirely I see two realistic options, not necessarily mutually exclusive. QGnomePlatform could create a KColorScheme definition with Adwaita-like colors and apply that to the application. If exuted correctly it would likely give very good results, but obviously only on platforms that use QGnomePlatform. The other option would be to programmatically derive a KColorScheme definition from a QPalette, which is likely much harder because KColorScheme is a superset of QPalette, but it would be a generic solution for all platforms.

The second noteworthy thing for KDE applications affects QML apps in particular. I’ve mentioned that QML has a separate theming system compared to QtWidgets. Because maintaining two style definitions for different systems is no joy KDE maintains a “hack” around this. qqc2-desktop-style implements a Qt Quick Controls style that fetches style information from a QStyle, which means all the existing QStyles out there keep working for QML apps. It works amazingly well, until it doesn’t. One of the shortcomings of this approach is that qqc2-desktop-style internally heavily relies on KColorScheme, which makes the aforementioned mismatch between QPalette and KColorScheme much more prominent. Possible solutions are the same as mentioned before.

I hope this gives some much needed overview over technology and terminology of involved components and helps with a productive way forward with addressing the problems we have. You are welcome to join this discussion. There’s some other relevant things to talk about, like icon loading, theming, and rendering, but that’s for another day.

The exact scope of this position is a bit vague. I like to describe it as “Taking care of everything needed so that people can build and enjoy awesome software”. A large part of that is taking care of foundational libraries such as Qt and KDE Frameworks, but it can be really anything that helps people do awesome things. This is pretty much what I’ve been doing as a volunteer for the last couple of years anyway.

So what have I been up to this past month? A lot, but also not a lot that’s worth mentioning individually right now. As you probably know we are heading full steam towards using Qt6 for all our products. This is something that started almost four years ago (and I’ve been involved from the start) and is growing ever more closely to being finished. Last week we switched Plasma master to use Qt6 exclusively, completing an important milestone for the whole transition. This involved a ton of small to medium-sized changes and fixes across the stack.

Instead of listing all the changes I have done as part of that let’s focus on the outcome instead: I’m typing this post running on a full Plasma session running against Qt6. There are still some rough edges, but overall it’s quite usable already. Definitely enough to get involved and hack on it. I’d show you a screenshot, but that would be pretty boring, it looks exactly the same as before!

So what does the future hold? The transition towards Qt6/KF6 is going to stay my focus for a while, but once that settles down I’m going to focus on other areas of our software platform eventually. If you have ideas for what it would make sense for me to focus on please get in touch.

This position is enabled and financed by KDE e.V.. To allow me to keep this position in the long term (and perhaps even hire additional people) please consider donating to KDE e.V.

For a long time this information has been available in a set of files in repo-metadata. To declare for example plasma-desktop’s dependency on plasma-workspace one would write the line

kde/workspace/plasma-desktop: kde/workspace/plasma-workspace

to the relevant file.

Since most projects depend on a lot of KDE Frameworks, and specifying each of the frameworks manually is somewhat cumbersome, a virtual frameworks/kf5umbrella project that depends on all frameworks was introduced. By default all projects depend on this helper project. This metadata was used both by the Jenkins-based build.kde.org CI and kdesrc-build.

The approach worked well enough, but had some drawbacks. First of all most projects don’t actually depend on all frameworks, so kdesrc-build would build projects that you don’t actually need, which is wasteful. Second, the format had no way for platform-specific adjustments, like defining that X depends on Y on Linux but not Windows. This was especially problematic for our Android builds, where it would try to build projects that don’t actually support Android or weren’t needed but increasing the size of the final APK. This problem was solved by moving our Android builds to use Craft, which maintains its own dependency metadata.

Because of these shortcomings when we replaced our Jenkins-based CI with Gitlab CI sysadmins came up with a new way of defining dependencies for each project. Instead of a single, global file with all information each project now has a .kde-ci.yml file in its repository that defines the dependencies. There is no equivalent of the kf5umbrella any more, which forces projects to explicitly list all of their frameworks dependencies. The new format also allows to define platform-specific dependency information. For example Neochat’s .kde-ci.yml looks like this:

Dependencies:
- 'on': ['@all']
  'require':
    'frameworks/extra-cmake-modules': '@stable'
    'frameworks/kcoreaddons': '@stable'
    'frameworks/kirigami': '@stable'
    'frameworks/ki18n': '@stable'
    'frameworks/kconfig': '@stable'
    'frameworks/syntax-highlighting': '@stable'
    'frameworks/kitemmodels': '@stable'
    'frameworks/knotifications': '@stable'
    'libraries/kquickimageeditor': '@stable'
    'frameworks/sonnet': '@stable'
    'libraries/kirigami-addons': '@latest'
    'third-party/libquotient': '@latest'
    'third-party/qtkeychain': '@latest'
    'third-party/cmark': '@latest'

- 'on': ['Windows', 'Linux', 'FreeBSD']
  'require':
    'frameworks/qqc2-desktop-style': '@stable'
    'frameworks/kio': '@stable'
    'frameworks/kwindowsystem': '@stable'
    'frameworks/kconfigwidgets': '@stable'

- 'on': ['Linux', 'FreeBSD']
  'require':
    'frameworks/kdbusaddons': '@stable'

However, kdesrc-build still uses the old dependency infomation. As it is natural for two instances of the same information, they eventually got out of sync and the metadata used by kdesrc-build got more and more incorrect. Something had to be done. Due to its architecture it isn’t really feasible for kdesrc-build to directly read the .kde-ci.yml files since that would require cloning the repos to read the data. Instead we opted to generate the old-style dependency data from the .kde-ci.yml files. In an attempt to learn Rust I wrote a tool that does this and committed the initial result. In the spirit of the recently announced Automation Goal this ought to be automated fully, but that’s for another day.

Any missing information in the generated data should be fixed by adding it to the relevant .kde-ci.yml file. If you find any other issues with the generated data please let me know.

To support more KDE-wide building-block initiatives like this KDE is hiring a Software Platform Engineer. Hiring people is enabled through your donations to KDE. Check out our End of Year Fundraiser that will enable more of this work to happen.

Happy kdesrc-building!

Photo by Joseph P. De Veaugh-Geiss.

During the sprint we set up a measurement lab for the KDE Eco initiative. Our goal is to make it as easy as possible for application developers to measure the energy consumption of their applications. To do this a stable and reliable measurement system that is available over a long timespan is needed. KDAB kindly offered to host such a system in their office.

The measurement lab currently consists of two severl-years-old mid-range desktop computers. The first part of the sprint was a discussion about what software environment the PCs should run. There are various considerations for this. The “Blauer Engel” measurement critera recommend using Ubuntu 20.04 for the measurements. Staying close to these recommendations makes sense. However, we want to be able to easily test new versions of KDE software, which often requires newer system libraries than Ubuntu 20.04 provides. We discussed using Flatpak as a declarative and reproducible way to provision specific versions of KDE software and their dependencies independent from the operating system. In the end we settled for using KUbuntu 22.04 on one and with KDE Neon.

After wiring up the machines and installing the chosen operating systems I set the machines up for remote access using SSH and remote desktop (VNC). Other people set up the power measurement infrastructure and how to access its data. There are some finishing touches to be done, including access control, before we can make the lab available to the KDE community. Once that is done we will share how to get access and make use of the lab.

During the day people also worked on other topics like alternative power measurement devices and data visualization. Check the official sprint blog post and Volker’s blog post for more details.

While hacking on the task manager code I noticed that we show a “Open new instance” action in the context menu of every task manager entry, even for those where it doesn’t make sense. A lot of apps are inherently single-window or single-instace, i.e. launching the app a second time will not open a second window but rather focus the existing one. Also, not all windows actually belong to a user-facing or user-launchable application. For example the network integration might ask you for the WiFi password, but you can’t open a new window for that from the task manager. Another kind of app where this actions doesn’t make sense is helper applications like the wizard for connecting to a new bluetooth device.

After some initial refactoring the first thing I did was hide the action for apps that have NoDisplay=true in their desktop file. These usually correspond to the aforementioned background services and helper apps. With that in the situation was improved for a great deal of windows. However, the case of single-window application was still unsolved. After reading some older, related discussion, I found that our friends at GNOME had solved this problem for them already. Their equivalent part of the code, amongst other heuristics, reads the X-GNOME-SingleWindow key from the application’s desktop file. So I did the obvious thing and added reading X-GNOME-SingleWindow to Plasma’s task manager code. We also added that key to a bunch of relevant KDE apps. While this was a pragmatic and working solution, relying on a X-GNOME- key for what we want to be cross-desktop behavior is not ideal. It’s time for standardization!

Nate Graham (you may have heard of him) proposed to add the existing key minus the X-GNOME- prefix to the desktop entry spec. After a bit of discussion about names and semantics people settled on SingleMainWindow as the new name. Implementations for Plasma and GNOME soon followed. What’s missing is adding it for all the apps out there. Besides KDE apps I already did that for qBittorrent, Nextcloud, and Yubico Authenticator. This is an excellent way to contribute to your favorite open source app!

But wait, there is more. Some apps define their own “Open new window” action in their desktop file. To avoid having two redundant actions Plasma now hides its own action when there is already a semantically similar one.

Happy task managing!

• Application titles: In addition to showing the window title Plasma’s task manager also shows the application name (the Name key in the desktop file). If the desktop file can’t be determined it falls back to the executable name, which isn’t particularly nice.
• Jumplist actions: Desktop files allow apps to specify additional application actions. For example Firefox allows you to open a new window or a new private browsing window by right-clicking on the entry in the task manager.
• Media player controls: Plasma’s task manager allows to control application’s media playback. You can e.g. pause a music player by right-clicking on its task manager entry. For this to work the window has to be matched to the MPRIS player instance, which happens based on the desktop file name.
• Recent files: Plasma’s task manager shows you recently used files for an application in the context menu for an application and allows to open that file in the app. This also relies on the desktop file mapping.

Now that we established why it is important to map a window to a desktop file, how is it done?

On Wayland the xdg-shell protocol, which is responsible for application windows, has builtin support for passing a desktop file name in form of set_app_id.

On X11, it’s more complicated.

For Qt applications the plasma-integration Qt Platform Theme sets a KDE-specific window property that contains the desktop file name. The task manager reads this property and handles it accordingly.

GTK apps have a very similar window property, named _GTK_APPLICATION_ID. However, until now Plasma did not use this information at all! Beginning with Plasma 5.25 the task manager will take _GTK_APPLICATION_ID into account, which fixes matching Gedit and other apps.

When neither _KDE_NET_WM_DESKTOP_FILE nor _GTK_APPLICATION_ID are set the task manager will use a wild guessing game heuristic to try and match the window to a desktop file. It takes into account things like the X11 window class, executable name, and Name and Exec from the desktop file. Sometimes this works well, sometimes it doesn’t.

These are just some examples why this mapping is so important. In a future post I will talk about an improvement to Plasma’s task manager in Plasma 5.24 that also requires this mapping to work.

This is due to the shell not being able to properly map a window to an application. This breaks more things than just icons, but those are often the first thing that is noticed. Fortunately this is usually very easy to fix, particularly for Qt/KDE apps. I fixed a couple of those over the holidays and now I am writing down what needs to be done so you know what to do the next time you encounter such a case.

Window to application mapping is based on the desktop entry name. That is the filename of the application’s .desktop file in /usr/share/applications/ (without the .desktop extension). For KWallet that would be org.kde.kwalletd5. Make sure your application actually has such a .desktop file installed to /usr/share/applications/. Most graphical apps have one, otherwise you wouldn’t be able to lauch it from the application launcher. However things that are not traditional applications, like services (e.g. KWallet) or helper applications (e.g. the Gwenview importer) don’t always have one yet. To avoid those showing up in the application laucher include NoDisplay=true in the .desktop file.

Now all we need to do is make sure that the window correctly reports the name of the .desktop file to the compositor. For Qt applications that boils down to making sure that QGuiApplication::desktopFileName() is correct. This can be as easy as calling QGuiApplication::setDesktopFileName("org.kde.kwalletd5"). For applications using KAboutData it can even be easier. If you have a KAboutData data("kwalletd5", ...) then QGuiApplication::desktopFileName() will automatically be set to org.kde.kwalletd5. The underlying heuristic can go wrong at times, in which case you need to override it using QGuiApplication::setDesktopFileName(). With those two things fixed KWallet shows a proper taskbar icon now:

See my next post for more detail on why mapping windows to desktop files is important.

Happy fixing!

FOSDEM

After writing an exam on Friday afternoon I took a train to Frankfurt. I did so not to enjoy the beautiful scenery of the area around Frankfurt central station at night but to be able to catch an early train towards Bruxelles for my first time at FOSDEM.

It has been a great experience to meet so many people interested in what KDE does at the KDE booth. It also was awesome to meet all the folks that are working hard on making Linux on the phone become a thing.

Pine64, Manjaro, UBports and KDE having dinner together

Plasma Mobile Sprint

FOSDEM went by in no time and so I found myself on a train to Berlin on Monday. My ride managed to defeat KDE Itinerary’s cancellation notification handling, but Volker managed to fight back.

In Berlin we met for a week-long Plasma Mobile sprint, hosted by KDAB in their offices. This gave us the opportunity to plan, discuss and hack all the things in a much more focused and productive manner than normally.

A particular pleasure was meeting Marius and Dalton from UBports/Ubuntu Touch and discussing how our projects can benefit each other. Most of our interactions was me nagging them to upgrade their Qt to allow KDE apps to run on Ubuntu Touch, but there was also fruitful discussion on sharing content between apps and a common push notification service (codenamed ‘Phushan’).

In addition to the discussion I also managed to get a few things done:

• We managed to build KTrip using Ubuntu Touch’s clickable build system (only for amd64, since crosscompiling Qt is a little more involved. If you find it easy please consider applying at KDAB).
• I started revamping the dated code of the dialer UI.
• Together with the Kaidan team I fixed an issue in KNotifications that was affecting them.
• Kaidan (XMPP client), Qrca (barcode scanner), Kookbook (recipe manager), Keysmith (OTP client) and Ruqola (Rocket.Chat client) are now available for Android in our nightly F-Droid repository.

On Saturday KDE joined UBports in their regular Q&A where we reported about the whole week and answered questions from the crowd. Check it out!

I left Berlin a bit earlier than planned due to an approaching storm, which was fine given how action-packed the whole week was.

Looking forward to doing it again!

Work on Qt 6 has begun and with Qt 6 a version 6 of the KDE Frameworks is due. This will gives us the opportunity to clean up and redesign some of our API.

Main goal for the sprint was to discuss the major design principles for KF6. I personally focussed on two aspects. First, we want to better separate logic from the user interface to allow different UI implementations for desktop and mobile uses. Futhermore, we want to reduce the amount of dependencies our libraries have. While we are doing fine for a lot of frameworks some have very ugly dependency structures. Probably our worst offender here is KIO, the framework that powers Dolphin and many more KDE applications.

This is the current dependency tree of KIO:

With some changes we discussed applied it could look like this:

Please note that all of this is highly tentative and might not always work out the way we imagine. While we can do some of these changes in the Frameworks 5 lifetime already most of it needs breaking API, so it will only be available in KF6.

This work will hopefully make KDE Frameworks more appealing for users outside of KDE. If you are developing Qt-based software and would like to know more about how KDE Frameworks can help you please contact us at #kde-devel on freenode or kde-frameworks-devel@kde.org

With Plasma Mobile KDE has been working on an alternative mobile platform for a while now. We now consider Plasma Mobile stable and suitable for everyone to use. Therefore we decided to stop developing KDE Connect for Android and focus on the Plasma Mobile experience. We have removed the app from Google Play and F-Droid as well as removed the public repositories. We are also in contact with Google about removing the active installations from devices.

We hope that this steps contributes to a better mobile experience in the long term beginning today, April 1st 2019.

Kirigami Pages

Kirigami apps are typically organized in Pages. Those are the different ‘Screens’ of an app. If you come from the Android world you can think of them as the view part of activities. In our case we want to have an initial page that offers to enter a stop or a destination and opens a new page that shows a list of possible routes. Clicking on one of the list items opens a new page with a detailed view about the connections.

Pages are organized in a pagestack where pages can be pushed and popped. On a phone only the topmost page is shown, whereas on a larger screen (desktop or tablet) multiple pages can be shown next to each other.

A single page on the phone

Two pages next to each other on the desktop

So let’s create some pages! I’m going put each page in its own .qml file and let the name end with Page. Our first version of StartPage.qml looks like this:

import QtQuick 2.2
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.4
import org.kde.kirigami 2.0 as Kirigami

Kirigami.Page
{
    title: "Start journey"
}

It produces an empty page with a title. Before we can actually see it we need to add it to the pageStack. Replace the Label {} declaration in main.qml with

pageStack.initialPage: Qt.resolvedUrl("StartPage.qml")

pageStack.initialPage is, well, setting the initial Page of the Page stack. Qt.resolveUrl is converting the relative URL of the QML file into an absolute one. Starting the app gives us an empty page

Time to fill it with some content.

Basic controls

On the start page we need need a way to enter start and destination of our journey as well as the date and time of our travel. For start and destination we are using simple TextFields from QtQuick Controls 2. Note that the older version 1 of QtQuick Controls is still around for the foreseable future, but we want to avoid using that. We’re extending StartPage.qml with our controls

ColumnLayout {
    width: parent.width

    Label {
        text: "From:"
    }
    TextField {
        Layout.fillWidth: true
        placeholderText: "Würzburg..."
    }
    Label {
        text: "To:"
    }
    TextField {
        Layout.fillWidth: true
        placeholderText: "Berlin..."
    }
}

A ColumnLayout is a component that positions its children vertically. We set it to be as wide as its parent, the page. The TextFields shall span the whole width as well. Instead of using the same ‘width: parent.width’ we are using ‘Layout.fillWidth: true’. This property is only available to children of a Layout. The difference to the first way is that all the width that is not already occupied by other elements in the layout is filled.

Next we need some way to enter a departure date and time. Unfortunately I’m not aware of any ready-to-use date and time pickers in QtQuick and Kirigami, so I’ll leave this open for a future post. For the time being two simple placeholder buttons shall be enough. Let’s add them to our ColumnLayout

RowLayout {
    width: parent.width
    Button {
        text: "Pick date"
        Layout.fillWidth: true
    }
    Button {
        text: "Pick time"
        Layout.fillWidth: true
    }
}

Now our app looks like this. Both buttons have the “Layout.fillWidth” property set to true, resulting in each one getting 50% of the space.

The buttons look a bit weird, don’t they? That’s because they are using the built-in QtQuick Controls style. If you are using Plasma you are probably used to the org.kde.desktop style which emulates the active Qt Widgets style. We can force our app to use the org.kde.desktop style by running ‘QT_QUICK_CONTROLS_STYLE=“org.kde.desktop” ./main.py’

Looks closer to what we have on the desktop, doesn’t it? Qt also offers a ‘material’ style that follows Android’s material guidelines

Next we need a way to press “Search”. We could solve that with yet another button, but Kirigami offers another way. Pages in Kirigami can have Actions associated with them. The presentation differes from the phone to the desktop. On the phone actions are displayed on the bottom where they are easily reachable while on the desktop they are displayed in form of a toolbar at the top of the page. Let’s add an action to our page

Kirigami.Page
{
    id: root

    title: "Start journey"

    actions.main: Kirigami.Action {
        icon.name: "search"
        text: "Search"
        onTriggered: pageStack.push(Qt.resolvedUrl("ConnectionsPage.qml"))
    }

    ColumnLayout { 

On the phone we get this

while on the desktop we get that

You can force the mobile view on the desktop by setting the QT_QUICK_CONTROLS_MOBILE variable to 1.

Triggering the action pushes ConnectionsPage.qml on the pageStack. Of cource we need to create that one now:

import QtQuick 2.2
import QtQuick.Layouts 1.1
import QtQuick.Controls 2.4
import org.kde.kirigami 2.4 as Kirigami

Kirigami.Page
{
    title: "Connections"
} 

Right now it’s just an empty page, we’re going to fill it with life in the next post.

You can find the full source code for all posts on Git.

Happy hacking!

KDE Connect is participating with 3 interesting projects that also involve other areas of KDE

1. Improving KDE Connect on Windows

KDE Connect builds and runs on Windows, but there are a lot of things that can be improved. This mostly involves the functionality that makes use of notifications. A large part of this task is about improving KNotifications on Windows.

2. An SMS app for Plasma Mobile

Plasma Mobile does not have a functional SMS app yet. We believe that the best way to create one is to reuse the SMS UI we’ve been developing for KDE Connect. We verified that the Plasma Mobile SMS stack is functional on the Nexus 5 (I have no information about other devices). The UI is already running on a phone, what’s missing is a backend that talks to ofono

3. Barcode scanning infrastructure

Scanning a barcode is one of those tasks that comes up in various different apps but the developers don’t want to implement it themselves. For those kind of tasks we have the Purpose framework in KDE. It allows the developer to specify a desired action and let the user choose from available services to fulfil them. E.g. the Share feature in Dolphin is implemented via Purpose. This task is about adding a new action type to Purpose that allows to scan a barcode. Possible implementations could use the local camera or the camera of a device connected via KDE Connect.

If you are interested in doing one of those tasks and have some basic understanding of C++ please contact us on #kdeconnect on Freenode or on Telegram.

The deadline for student applications is April 9th and composing a good application takes some time, so please contact us rather soon.

Please note that we require students to have done some minor work (e.g bug fixes) before starting GSoC. Don’t worry if you don’t have done anything yet, there is still time for it ;)

Happy hacking!

One app that is essential for my use case is an app that allows me to check departures and routes for public transport. Since I’m not aware of any existing one I decided to do my own and share my road here. The purpose of this is to be educating for both me and you and to inspire you to create your own mobile-friendly Linux apps.

Like the other KDE mobile apps I’m going to use QML/QtQuick and Kirigami. QML is the declarative UI language from the Qt project. Unlike the older QWidgets it is designed with (embedded) touch systems in mind and thus is ideal for mobile apps. Kirigami is a set of QtQuick components designed for creating convergent mobile/desktop apps.

Unlike other KDE projects I’m not going to use C++ for the business logic. Instead I’m going to use Python, which is now officially supported by Qt. Since my Python skills are fairly basic this will be a fun challenge for me. Therefore take everything I write with a grain of salt and feel free to point out anything that is wrong or can be improved.

This won’t be a 100% complete reference for developing for Plasma Mobile, but I’ll try to cover as many different aspects as fit into the concept of this app. I’ll also try to focus on one aspect/feature/goal per post. Also most of this will not be specific to Plasma Mobile but will work on any desktop or mobile Linux.

So lets get started :)

Part 0: Basic application

Before getting started we need to install a few things. First of all we need Python (obviously) and Qt for Python. Qt for Python was formerly known as PySide2. You can install it via ‘pip install pyside2’. Next there is Kirigami. On Ubuntu you can install it via ‘sudo apt install qml-module-org-kde-kirigami2’.

After that we can start coding. The following main.py file is creating an app and loading the UI from a .qml file. The exact details are not too important at this point.

#!/usr/bin/env python3

from PySide2.QtGui import QGuiApplication
from PySide2.QtQml import QQmlApplicationEngine

if __name__ == "__main__":
    app = QGuiApplication()
    engine = QQmlApplicationEngine()

    context = engine.rootContext()
    engine.load("qml/main.qml")

    if len(engine.rootObjects()) == 0:
        quit()
    app.exec_() 

Next we need to define our UI in a QML file. To keep things organized we are going to put our QML files in a qml/ subfolder. Our first main.qml is rather simple

import QtQuick 2.2
import QtQuick.Controls 2.4
import org.kde.kirigami 2.0 as Kirigami

Kirigami.ApplicationWindow
{
    width: 480
    height: 720

    Label {
        text: "Hello world!"
        anchors.centerIn: parent
    }
}

width and height are a bit arbitrary since the window will always be maximized on the phone, but this way we get a somewhat realistic window on the desktop. Executing the python file should result in something like this

In the next post we are going to fill this window with more life using QtQuick and Kirigami components. Stay tuned :)

The source code will be available at https://invent.kde.org/nicolasfella/kstraba

Targeting Android Oreo

As of this month app updates uploaded to Google Play need to target Android 8. This has several implications. Targeting Oreo comes with an updated Support Library, which forces us to drop support for Android 4.0 and below. According to our Google Play data this will affect approximately 400 users. We are very sorry about that, but these users won’t receive further updates. Furthermore, Android Oreo introduced some restrictions in regard to apps running in the background. In the future in order to be able to run in the background KDE Connect needs to show a persistent notification. The good news is that you can hide the notification. The (slightly) bad news is that we cannot do it by default. To hide the notification you need to long-press it and switch it off. Other notifications from KDE Connect are unaffected by this.

1.10 Changes

These are the main changes of version 1.10. Not mentioned are countless small improvements and under-the-hood changes. Mouse input now works with the same speed independent from the phones pixel density. The media controller now allows stopping playback. Run command supports triggering commands using kdeconnect:// URLs. Useful for integration with NFC tags and 3rd-party apps. The notification filter allows quickly (de-)selecting all apps. Several settings scatterd across the UI have been bundled into a single settings screen. A lot of work has gone into how we handle SMS on the Android side in preparation for something huge. Stay tuned ;)

Other changes

The desktop side has improved as well since my last post. The windows build of KDE Connect gained support for keyboard input. The plasmoid gained a couple of additions. In my last update I mentioned that it is possible to run commands from there. It is now also possible to lauch the command setup from there. Furthermore it is now possible to select files to share them from there. The Linux Mobile App gained many visual improvements and features. It now supports sharing files and controlling the system volume. If you are using Itinerary you can send booking information from the PC directly to the phone via KDE Connect. It is now possible to send files directly from Pantheon Files (and other Elementary apps) and Thunar via KDE Connect. Again, there are countless other improvements that I did not explicitly mention. A big thanks to all people who contributed to this!

The Dolphin context menu entry for sending files to a connected device has been dropped in favour of a Purpose plugin, which groups nicely with other Share features and supports more apps such as Okular and Spectacle. Albert Vaka added a presentation mode to Android which allows you to control slideshows from your phone. Aleix Pol added the same to the Kirigami app.   As I’ve mentioned before it is quite hard to find the settings where you can define your commands for the Run Command feature.  The command list on Android now has a button that opens the appropriate settings on the desktop. Ivan Čukić added a few useful command suggestions to the menu. Friedrich Kossebau added support for a “Find my PC” plugin. You might wonder now how often he loses his PC, but it also helps finding other devices that run the C++ version of KDE Connect, such as Plasma Mobile and SailfishOS devices. I added support for triggering it on the Android side. Following a request on Reddit I added a dedicated Stop button to the media controller. Chansol Yang made sure that the pointer speed when controlling the mouse from the phone is the same across Android devices with various DPIs. Philip Cohn-Cort added the much requested dark theme option to Android. You can now use special URLs to trigger commands on connected devices. The urls have the form kdeconnect://runcommand//. As those are quite complex I added a helper for it. You can copy an URL to the clipboard by long-pressing a command in the command list. You can write those URLs into a NFC tag to trigger the command when your phone reads the tag or use it to integrate with services such as Tasker. The system volume patches have been merged. To make use of it you will need the latest KDE Connect from master for Desktop and Android and pulseaudio-qt installed. You can get pulseaudio-qt from git. We will to an initial 0.1 release soon and hope that distros will ship it soon. Besides these features we also fixed some bugs and polished the UI a little. Bluetooth support is progressing slowly. Matthijs Tijnk and Qt 5.11 fixed some issues. However, it is still not ready for the public. We also improved our device support: Aleix and I improved the Kirigami app. We improved the basic pairing workflow and  you can now run commands and control media sessions. Bart Ribbers fixed an issue that was blocking KDE Connect from building it for postmarketOS. I hope to see KDE Connect there as well! Adam Pigg made a huge step towards bringing KDE Connect to Sailfish OS. We like to see KDE Connect on as many platforms as possible, and we need your help for it! Our workboard contains lots of ideas for new people to get started. You can ask for any assistance in our Telegram group. Thanks to all contributors!

• Send via Bluetooth and send via KDE Connect are still separate in Dolphin’s context menu and should be in the ‘Share’ sub-menu as well. I 100% agree on that. In fact send via KDE Connect is already in the ‘Share’ sub-menu and I’ve uploaded a patch to remove the old entry. As for Send via Bluetooth: Someone would need to turn Bluedevils FileItemActionPlugin into a Purpose plugin. I’ll probably do it myself as soon as I find the time for it.
• Dolphin’s context menu will be even more cluttered with this. It actually achieves the opposite. By combining actions like Send via Bluetooth and Send via KDE Connect into a sub-menu the top-level menu will be less cluttered.
• I’m not going to use it, so I don’t want to have it. You can disable it in Dolphin’s settings.
• I’m never going to use option XY, but it’s still there. Fair point. Some options are loaded conditionally, so e.g. the Telegram option is only present if Telegram is actually installed. For others this is not the case. I’m planning to make a config module to en-/disable options.
• I don’t want to share my files by accident. Virtually all of the options require more than one click to do something, so it needs a weird accident to actually do something unwanted.

I’d love to see more applications/services adopting Purpose. So if you are a developer interested in integrating your application with Purpose please get in touch with me and we will figure out a solution. I’m especially looking at you, fellow KDE developers ;) Happy sharing :)

How far are we?

Thanks to Aleix Pol there is a suitable UI for KDE Connect on Plasma Mobile already in our git tree. I was able to run it on Plasma Mobile. It has some rough edges, but is basically functional. Some features that work so far:

• Control media players
• Remote mouse input
• Lock the remote device
• Find the remote device
• Receive files
• Receive remote commands

Why do I care about Plasma Mobile at all?

Chances are high that you won’t be dropping your Android phone for Plasma Mobile anytime soon. But even then you will be profiting from our efforts. To achieve feature parity with Android we will need to port some of the Android features to C++/Qt. This will benefit all your connected devices that run the C++ version of KDE Connect, e.g. other desktop devices, Sailfish OS phones or phones/tablets running another version of Linux (e.g. Ubuntu Touch). The new UI also provides room to integrate some controls that are only available on Plasma right now. This will improve the KDE Connect experience for non-Plasma desktop users.

Sounds great, what can I do?

You want to help? Awesome! I created a meta-task on Phabricator to track the current progress. It contains all the things that should be done as sub-tasks. Some of them are ideal beginner tasks. Just pick one you like and don’t be shy to ask for help. You don’t even need to have a phone running Plasma mobile to do it, you can develop it on your desktop machine and thanks to the awesome Kirigami Framework it will run on Plasma Mobile automagically. What are you waiting for?

• Lack of language diversity results in poor translations for non-widespoken languages and other internationalization issues
• Having only English/German/Spanish/French speaking contributors leads to incomplete support for things like right-to-left layouts and CJK characters/input methods
• Contributors with powerful hardware and good internet connection tend to ignore the need for performance- and bandwidth-efficient solutions
• An example from KDE Connect: Most of us are from Europe where its common to use messengers like Whatsapp whereas in the USA it’s far more common to write SMS. Therefore we didn’t really had in mind that it’s important to have good SMS integration in KDE Connect until we actually had some people from the US at our sprint
• People tend to not be aware of different setups other people might have, e.g. having an Android phone without Google Play Services is rare in Europe but common in China

To address these issues I am aiming to ease contribution for everyone. I believe that KDE Connect is a great project to get started in KDE development. After all, it’s the project I got started with myself. The codebase is small and IMHO quite sane. The modular architecture allows you to quickly get cool results without risking to break stuff. To help you pick a task for your first contribution I started marking tasks as junior jobs on the KDE Connect workboard. I want to provide structured information for each task that helps you diving into it. I hope that other KDE projects will follow our lead.

Now I need your help!

Which information would you like to see in the task description? What can we, the established developers do to make your first contribution easier? What were the problems you encountered in your first contribution? What are the lessons you learned during your first contributions that you want to share with others? If you already have a KDE Identity account please leave your feedback on the Streamlined onboarding of new contributors or the Junior Jobs task. If you don’t please leave your feedback here in the comments and I will forward it to the appropriate places. Your help will improve the overall community and thus the quality of our software in the long term!

Implementation

The idea for this has been around for a while, but it was not until fall 2017 that I actually started implementing it. The implementation relies on PulseAudio. We are aware that not everyone is using it, so we don’t require it and hope that packagers do not make KDE Connect depend on PulseAudio. The first implementation was using the command line tool pactl to set the volume. Assuming you only have one sink it was working pretty well, except there was no easy way to ask for the current volume, so our volume slider would be wrong pretty often. I got around this by parsing the output of pactl in a horrible, horrible line of bash, but it was clear that this was not stable enough to actually go into prod. Also it was still not working with multiple sinks. The logical step was to make use of the libpulse. For some reasons there are a great deal of people that like the C programming language, but I don’t. Especially not the library style that comes with it. What I really didn’t like was the idea of mixing low-level libpulse C code with high-level Qt code. Luckily, the Plasma guys thought the same. The Plasma Volume Applet contains code that was acting as a bridge between the two worlds. So I “borrowed’ that code (isn’t free software amazing?) and after some intense head-against-the-table banging (turns out both KDE Connect and Plasma PA both have a class ‘Device’ with the same include guard) it was working like a breeze, now even with multiple sinks.

Birth of a Framework

It was working really good, but the thought of having 20 files of duplicate code in two KDE projects wasn’t particularly appealing. We decided it would be best to extract the common code into a library that both projects can use. To make this possible the code needed quite some polish. The original author probably didn’t have in mind that it might become a library someday. After some work we now believe that the API can be declared stable and it can be released on KDE Extragear. We aim to make it an official KDE Framework once the code has matured enough. Extracting and releasing it as a library makes it easier for us to maintain it, but it also means that you can use it in your project! Furthermore, since it covers more use cases than just volume control it’s also possible to integrate more PulseAudio related features into KDE Connect easily. We are looking forward to your suggestions!

KDE Connect is not tied to Plasma

Many times people claim that KDE Connect is tied to Plasma. KDE Connect can be used with any desktop environment or even no desktop environment at all. A small portion of the UI is only available in Plasma, but most functionality is available on all platforms. However, most KDE Connect developers use Plasma, so issues in other DEs don’t come to our attention in our daily usage. If you find something that can improve the non-Plasma UX, please let us know by filing a bug. If you are using Gnome you might be interested in GSConnect, a GNOME Shell extension that uses KDE Connects Android app. If you are using another GTK-based desktop you might want to install indicator-kdeconnect. The misconception that KDE Connect is tied to Plasma likely comes from the fact that on some distros such as Debian the KDE Connect package depends on Plasma. This should **not **be the case and is highly discouraged by us. Please file a bug against your distros package if that is the case.

Add devices by IP

KDE Connect tries to discover devices in your network automatically. However, for various networking reasons this does not work in all cases. If your devices are not automatically discovered, but you are able to ping one device from another there is a good chance you can pair them by adding the device IP manually. Open up KDE Connect in your phone, go to ‘pair new device’, tap the three dots in the top-right corner and tap ‘Add devices by IP’. You can both specify IP addresses and hostnames.

Filter notifications

Many messaging apps like Telegram got a desktop or web client. In this case you would get double notifications for each message, one from the phone over KDE Connect and one from the desktop client. In this case you want to take your phone, go to the ‘Plugin Settings’ and select ‘Notification sync’. You will get a list of all your installed apps and can select from which you want to receive notifications.

Runcommand Plugin

We receive a lot of feature request and are thankful for that. The bad news is, we cannot implement all of them. Some use cases are just too special. The good news is, we implemented a plugin that can serve a infinite number of use cases. You can specify commands on your desktop and can run them from your phone anytime. For example you can create a Shutdown command to power off your computer without leaving your bed. You can even create bash or Python scripts (or anything that is executable from bash) to do anything you can imagine. The best news is, it is already there. This has been around for quite a while, but most people didn’t know about it because it’s very hidden. We’re trying to make it more discoverable in an upcoming release. Right now you need to go to the system settings, select the Runcommand Plugin preferences and enter your commands. We’re aiming towards a better UX for this, but even right now, the possibilities are endless.

Rename devices

Sometimes you may want to rename one of your devices, e.g. when you have two from the same manufacturer and they show up with the same name. On the desktop side, go to the KDE Connect settings and in the top-left you will find a edit button. It’s the little pencil icon in the above screenshot. On Android it’s a little bit more hidden. Open up the left drawer and tap your devices name (in my case “The phone”) to edit it.

Notifications on the phone

One of the most loved features about KDE Connect is receiving your phones notifications on the desktop. But did you know that you can also do it the other way around? All you need to do is go to the settings on the phone and on the desktop, activate the “Receive notifications” plugin on Android and the “Send notifications” plugin on the desktop and enjoy your desktops notifications on the phone.

Keep screen unlocked

Another plugin that’s been around for a while but deactivated by default is the screensaver inhibitor. When you choose to activate it in the settings your screen won’t power off as long as your phone is connected.

Pair Desktop to Desktop

You can not only pair a phone with your desktop device, you can also pair a desktop with another desktop. It isn’t as powerful as connecting a phone with a desktop, but you can still do useful things like sharing files and links. We are looking to extending the capabilities. The same also works for two android devices.   I hope I could provide you some useful knowledge that makes you enjoy KDE Connect even more. As usual, if you want to support our development please consider donating to KDE.

Remote Keyboard plugin

I think most of us can agree that typing long texts on the phone sucks compared to typing on a proper keyboard. Before, you could type your text on the desktop and copy & paste it to your phone using our clipboard sync. Now we got an even fancier method: our new Remote Keyboard plugin. Before using it you need to enable the KDE Connect Remote Keyboard in your phones settings. Whenever you are confronted with a text input field you can switch to the KDE Connect Remote Keyboard. Then you open up the Plasmoid, click the input field and start typing. Big thanks to Holger Kaelberer for implementing this!  

Reply to Whatsapp and others

Previously you only could reply to SMS, but not other IM apps like Whatsapp. We are pleased to announce that we were able to enable replying for several other messaging apps that support Androids quick reply, including Whatsapp. Please note that it is not within our control which apps are supported and which not. Big thanks to Julian Wolff for implementing this!  

Notification icons

On Android, most notifications have some kind of icon, like a contact picture for messaging apps or album art for media player notifications. KDE Connect now forwards those and displays them on the desktop and inside the Plasmoid.  

Runtime permissions

Android Marshmallow introduced a new permission system, giving the users fine-grained control about their apps. To support this new system each plugin got a set of required and optional permissions assigned. If a required permission has not been granted the respective plugin won’t be loaded. If an optional permission has not been granted the plugin will be loaded with reduced features.  

Direct share

Android Marshmallow also introduced Direct Share. Using this we enabled you to send files or urls to your desktop without opening KDE Connect.  

Plasmoid redesign

Our Plasmoid got some love Before: After:  

Choose ringtone for Find-my-Phone

A small but requested feature is selecting a ringtone for Find-my-Phone.  

Blacklist numbers

You are now able to blacklist numbers so that calls and SMS are not forwarded to the desktop. This is especially useful when you are using two-factor-authentification with your phone so it won’t get leaked to the desktop. Those features were implemented by me.  

Media controller overhaul

Matthijs Tijink has been working really hard on improving the media controller plugin. It now displays the album cover art and a media control notification as well as other polish. Make sure to check out his blog. Before: After: Notification:  

URL handler

Aleix Pol has implemented an URL handler that enables you to trigger phone calls for example by clicking a tel:// url in your browser.   Additionally we have fixed loads of bugs, crashes and papercuts and made many under-the-hood improvements. There is also a lot going on in related KDE software. Friedrich Kossebau is working on bringing MPRIS support to Gwenview and Okular, enabling controlling slideshows and presentations from KDE Connect. Furthermore we fixed some issues in the MPRIS implementation of Plasma Browser Integration and Elisa (the next-gen KDE music player). Speaking of Plasma Browser Integration: In case you haven’t, make sure to check out this awesome project which integrates neatly with KDE Connect, enabling you for example to control Youtube videos or Netflix from your phone or to send browser tabs to your phone. Thanks Kai Uwe Broulik for this awesome project! But this is not the end. We got some more features in the pipeline and this week the core developers are meeting for a sprint to discuss the future of KDE Connect. Some weeks ago we asked people on Reddit which features they like to see and got a ton of valuable feedback. We’ll discuss it and let you know which of them are feasible. If you are as excited about KDE Connect as we are we would love to see you join our development team. Make sure to subscribe to and ask for help at our mailing list. If you can’t contribute in a technical way but still want to support us consider donating to KDE. Your donations enable us to meet in person and work more closely on KDE Connect and other KDE Software.