Posts on Nico's blog

Month two as KDE Software Platform Engineer

2023-04-08T16:00:00+02:00

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

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

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

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

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

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

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

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

Building Plasma against Qt6

2023-03-26T18:00:00+02:00

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

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

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

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

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

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

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

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

Now for some question that might be on your mind:

Q: Is it stable?

A: No, see above.

Q: When will it be stable?

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

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

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

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

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

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

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

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

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

How platform integration in Qt/KDE apps works

2023-03-09T21:00:00+01:00

There has been some recent discussions about how KDE applications (or Qt apps in general) should look and feel like outside of the Plasma desktop, particularly in a GNOME environment.

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 exaclty 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.

A month as KDE Software Platform Engineer

2023-03-06T13:00:00+01:00

Precisely one month ago I joined KDE e.V., the non-profit organization behind KDE, as Software Platform Engineer. This is part of three positions in KDE’s “Make a living” initiative.

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.

Generating Dependency Data for kdesrc-build

2022-12-09T13:00:00+01:00

As you may know KDE consists of many different subprojects, where some projects depend on other projects. Most KDE projects depend on some KDE Frameworks, but other dependencies are also possible, e.g. plasma-desktop depends on plasma-workspace. To be able to automate building projects (for the CI system or tools like kdesrc-build) you need a machine-readable source of dependency information.

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!

KDE Eco Sprint 2022

2022-05-30T16:00:00+02:00

Last weekend, on May 21st, some people (including me) met in Berlin for what I believe is the first in-person KDE sprint since you-know-what happened (there was LAS, but that’s not technically a KDE sprint). We met in KDAB’s office, which was incidentally also the location of the last in-person sprint before unamed things happened.

+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.

Task Manager Improvements in Plasma 5.24

2022-02-18T01:00:00+01:00

In my last post I talked about why knowing the desktop file for a window is important for the task manager. I promised to talk about some cool stuff we did there in Plasma 5.24, so here we are.

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!

The importance of window to desktop file mapping

2022-01-11T01:00:00+01:00

In my last post I talked about what application developers can do to fix their applications not showing up correctly in Plasma’s task manager. I motivated this by the fact that we need this on Wayland to display the app’s icon. However icons are not the only reason why correctly mapping windows to desktop files is important. It brings substantial benefits even on X11:

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.

Fixing Wayland taskbar icons

2021-12-26T02:00:00+01:00

A common papercut in a Wayland session is entries in the task manager showing a generic Wayland icon instead of the proper application icon. Here’s a KWallet window having a generic icon in the task manager (on the right):

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 & Plasma Mobile Sprint

2020-02-16T23:42:13+00:00

Last week I decided to take KDE Itinerary for a test tour. Between the train rides there was also time for some KDE stuff.

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!

KDE Frameworks 6 sprint

2019-11-29T20:08:50+00:00

Last week I took a train to Berlin for the KDE Frameworks 6 kickoff sprint. A lot has been said about it by my fellow attendees already, so I won’t go into detail much.

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

KDE Connect and Android

2019-04-01T10:00:50+00:00

As most of you know KDE Connect has recently been removed from Google Play due to a policy violation with regard to our SMS and telephony features. While the public outcry helped to get it back in with all features remaining this is just yet another example of how new Android policies make it harder for us to maintain the level of quality and features you expect from KDE Connect. Android Oreo forced us to drop support for older Android versions and imposed restrictions on background services which force us to have an annoying persistent notification. It is to be expected that Google will further restrict background services which will impose more problems for us. With each new Android versions new restrictions and problems arise which we have to work around, if possible. For example, the upcoming Android Q imposes restrictions on accessing the phone’s clipboard. It is unclear whether the clipboard sync in it’s current form is feasible on Android Q. Those are just examples of the problems with the direction Android is moving towards.

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.

Creating a Plasma Mobile App 1 - Basic Controls

2019-02-28T20:32:15+00:00

My last post shows how to create a stub Python/Kirigami app that doesn’t do anything. Time to change that! In this post we’re filling the screen with some controls.

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!

Google Summer of Code with KDE Connect

2019-02-28T17:59:04+00:00

KDE is happy to announce that we will be part of Google Summer of Code 2019. GSoC is a program where students recieve stipends to work on free software for 3 months. Getting paid for open source work, that’s the dream, right?

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!

Creating a Plasma Mobile application

2019-02-20T21:16:15+00:00

From February 4th until February 9th I attended a Plasma Mobile sprint in Berlin, Germany. I met a lot of people that share the vision of an open, privacy-friendly mobile platform. However, we all agree that such a platform can only succeed if there are enough people sharing that vision creating suitable apps for it. There already is a nice amount of mobile-friendly Linux apps, many of them created by the KDE Community, but of course we need more :)

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

KDE Connect - New stuff 0x3

2018-11-04T22:14:13+00:00

Today we released version 1.10 of the KDE Connect Android app. Therefore it’s time again to share what we’ve been working on.

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!

KDE Connect on IRC and Matrix.org

2018-09-07T15:38:12+00:00

Since a few months KDE Connect has a Telegram group to discuss development. Since the over 100 people joined. I did not expect such an interest in it. Few people asked to have this group bridged to an IRC channel since they prefer IRC over Telegram. I’m happy to announce that we finally made this happen. Let’s celebrate the birth of #kdeconnect on Freenode. You can also access it from matrix.org (#freenode_#kdeconnect:matrix.org). The rest is up to you! If you are interested in contributing to KDE Connect go and share your ideas with us and ask any question you have!

KDE Connect - New Stuff II

2018-07-31T14:30:46+00:00

It’s time for another feature update for KDE Connect! You can now run commands on connected devices from the Plasmoid.

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!

The Purpose of things

2018-07-08T21:28:10+00:00

Hi, For once this is not a post about KDE Connect (at least not directly). Besides KDE Connect I also work on several other KDE projects, one of them being the awesome Purpose framework created by Aleix Pol. After Nate highlighted my latest work on Purpose (the new share menu in Dolphin) in his blog post I received quite some feedback. I’m glad that many people like the idea, but I also received some criticism/suggestions for improvements. This is always welcome as long as it is fair and objective. This was true for most comments, but unfortunately not all of them. I won’t even bother to reply to unfair and personal attacks for a useful feature, but rather like to respond to appropriate criticism and inform you about my future plans for Purpose. First of all, for those who don’t know what Purpose is, it is an extensible framework to fulfill the developer’s purpose while providing an abstraction. Right now the only use-case is exporting/sharing a file, but more could be added in the future. It is used by Dolphin, Spectacle, Okular and other KDE applications and can export files to Email, Telepathy, KDE Connect, Nextcloud, Telegram (I did that one myself), Twitter, Imgur and many more. For the share menu in Dolphin’s I received some critisism/suggestions for improvements:

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 :)

KDE Connect on Plasma Mobile

2018-06-07T17:59:00+00:00

The digital world has changed over the last 10 years. The usage of mobile devices skyrocketed whereas the desktop market is stagnating. The trend is also going towards smaller and convertible devices. The mobile market is controlled by two major corporations. One of them is religiously cutting down your personal freedom and aiming towards a walled garden proprietary ecosystem, the other one is disrespecting your privacy enormously. With Plasma Mobile the KDE community is envisioning a mobile experience that is giving you maximal freedom while ensuring your privacy. It seems like a bold venture, but we have to at least try, right? Plasma Mobile would not be a true KDE project without the same degree of integration with the desktop as we already have with Android devices. Therefore we aim to make Plasma Mobile a first-class citizen of KDE Connect.

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?

KDE Connect Junior Jobs

2018-05-13T11:16:59+00:00

One of KDE’s Community goals for the next years is streamlined onboarding of new contributors. It’s very important that new people regularly join the community for various reasons. First of all, there will always be something to do and the more contributors the merrier! But there are also people becoming very inactive or leaving the community and these people need to be replaced. Furthermore new people bring in new and fresh ideas. It’s important to have people from diverse backgrounds in the community. Lack of community diversity manifests in several issues:

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!

Volume Control in KDE Connect

2018-04-30T16:47:31+00:00

Definitely one of the best use cases of KDE Connect is this: Watching a movie while laying in bed or on the couch and controlling your unreachable computer from your phone without needing to stand up. Thanks to our new media control notification you can pause and skip without even unlocking your phone. But what if the movie is too silent? If your media player is implementing the MPRIS2 specifications you are already lucky and can control your players volume from KDE Connect. Plasma Browser Integration even adds that for Browsers. But what if your player doesn’t support it (looking at you, Spotify)? Or you want to control your system volume? Then you are out of luck. Until soon. We are adding a plugin to KDE Connect that enables you to control your system volume from the phone. How cool is that? Another neat little trick is tapping on the volume icon to (un)mute the system.

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 - Tips, Tricks and Misconceptions

2018-04-04T05:00:42+00:00

Since my first blog post we got an huge amount of feedback and it’s amazing to see that you are as excited about KDE Connect as we are. This way I want to say “Thank you” for all your kind words and tell you that this kind of positive feedback is what keeps us going. I would also like to share some tips and tricks about KDE Connect that you might not know yet, but first I would like to clear up a common misconception.

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.

Building KDE Connect

2018-03-30T10:54:49+00:00

After I shared the link to the KDE Connect Development Telegram group almost 20 people joined within 24 hours. I certainly did not expect such a interest in KDE Connect. When I joined the project about a year ago the hardest part for me was setting up a proper development workflow, meaning configuring, building, installing and debugging the application and interacting with git and Phabricator. To ease your start in KDE Connect development I would like to give you the guide I wish I had back then. I will show you how to fetch the project, build, run and debug it using KDevelop. It’s an IDE by the KDE Community designed with KDE projects in mind. In theory you can use any IDE you like, if you figure out how to configure it properly. You probably will find KDevelop in your distros repository. Install and run it. Go to Project -> Fetch Project… Search for KDE Connect client for KDE and click Get After the project is fetched you click Next -> Next -> Finished The install prefix determines where KDE Connect will be installed. Choose /usr if you want to override your distros package. In this case you might want to uninstall it. Hit OK. If you are getting cmake errors you are missing some development packages. The name of those depend on your distro. For example, the development package for KIO on Ubuntu is called libkf5kio-dev. Google should help you find all required packages for your distro. On Debian/Ubuntu you can use “apt-get build-dep kdeconnect” to install the build dependencies. On openSUSE you can install the dependencies using “sudo zypper si -d kdeconnect-kde”. After you installed all required packages hit Build in the top-left corner. Make sure there is no other instance of KDE Connect running by running “killall kdeconnectd” After it build successfully hit Debug. You will be prompted with a window to configure the launch. You will need to do this only once. Hit Add -> Project Executables -> KDE Connect -> daemon/kdeconnectd . If this does not work you might need to adjust the path to the kdeconnectd binary. Hit OK and you should have a running KDE Connect built from source! Now, if you do any changes to KDE Connect you just need to hit Build and Debug again to apply it.

KDE Connect - New stuff I

2018-03-29T21:40:25+00:00

As I said a couple of days ago we got a lot to announce for KDE Connect. This is the first of many posts where I show you what we were up to. It may not be as exciting as you hoped for because the really big features are not-quite-ready, so hang on :) First we squashed some bugs, including a pretty nasty crash in the NotificationsPlugin. In my first post about KDE Connect I told you about the album cover art on Android. Thanks to Matthijs it now also works when the cover art is a local file, for example when you are using VLC. It already worked when the cover art was a remote URL, for example with Spotify. The cover art is now also shown in the media control notification and added to the Android media session. When you send an image to you phone the notification now contains a preview of the image. The notification now also has a share button which allows you to quickly do something with the just received file. If you use Nautilus as a file manager you will be pleased to hear that KDE Connect now includes a Nautilus extension that allows you to quickly share files across your devices. As I mentioned before, the exciting features are yet to come. Now is a perfect time to join our development team! The codebase is stable and allows you to quickly implement new features. If you got a basic understanding of programming you can quickly get a grasp on the technologies we are using (Java/Android and C++/Qt). If you are interested please join our Telegram group. Please note that this is a development group and not a general support group. Stay tuned!

KDE Connect Sprint

2018-03-26T17:10:00+00:00

Last weekend the core KDE Connect development team met for a sprint at the amazing Verse office in Barcelona. It was an amazing opportunity to get to know each other (most of us have never met before) and discuss the future of KDE Connect in an amazing and productive atmosphere. We squashed some bugs, implemented new features and laid the foundation for other ones. Some weeks ago we asked people on Reddit which features they liked to see in KDE Connect. We discussed them extensively and are pleased to say that some of the most requested ones are already in progress. We will announce more in the next couple of weeks. Stay tuned! This sprint was only possible because KDE e.V. provides travel support for us. If you want us and other KDE Projects to be able to meet in person more often please consider donating to KDE e.V.

KDE Connect - State of the union

2018-03-20T01:23:16+00:00

Hey there! We haven’t blogged about KDE Connect in a long time, but that doesn’t mean that we’ve been lazy. Some new people have joined the project and together we have implemented some exciting features. Our last post was about version 1.0, but recently we released version 1.8 of the Android app and 1.2.1 of the desktop component some time ago, which we did not blog about yet. Until now! We got some fancy new features in place:

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.

+ +

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.