I’ve been quiet since Akademy. Before that, the silence was mostly due to studying multiple books about technical writing for my talk.

After that, I had certain tasks left to do: Kirigami Addons and KConfig. The former requires a proper revision on my part to be finished, and KConfig is almost ready, but I struggled quite a bit with the solution to a problem I was having.

I moved on to focus temporarily on other matters that I’m going to handle in the near future. This blog post doesn’t provide the solutions to these matters, but it mentions my plans, which might interest you or give you a clear perspective on what I’ve been doing. The post will feel incomplete because it is a checklist. If you wish, you can skip to the end summary.

KNotifications is KDE’s framework for creating popup notifications. It supports Linux, Windows, macOS, and Android, making it, to my knowledge, the most complete cross-platform library for this available in C++. This makes it natually interesting to use for non-KDE Qt application developers.

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

This is a sort-of reply to Herzenschein’s blog post from a few months ago. He goes over how to tell KConfig put it’s files into app-specific folders instead of dumping them into the garbage bin of ~/.config. He noted that he hasn’t touched KConfigXT yet, so this is how to make it work with KConfigXT applications.

However you’ll notice by default KConfigXT generates constructors for your configuration class like this:

class Config : public KConfigSkeleton
{
  Q_OBJECT
  public:

    Config( QObject *parent );
    ~Config() override;
...

That’s not useful, and it took me a minute to figure out how to allow KConfigSkeleton and the KConfig compiler to let me pass AppConfigLocation. However, the solution is very simple.

First, you need to make sure it’s not a Singleton. (There’s probably a way to make it work with a singleton though.) Make sure that setting is turned off in your .kcfgc:

File=config.kcfg
ClassName=Config
Mutators=true
DefaultValueGetters=true
GenerateProperties=true
Singleton=false

And then in your .kcfg, modify the <kcfgfile> block to add arg = "true" instead of hardcoding a filename. It will look something like this:

<kcfgfile arg="true" />

Once you run the compiler again, you’ll get a constructor that allows you to pass a KSharedConfig!

class Config : public KConfigSkeleton
{
  Q_OBJECT
  public:

    Config( KSharedConfig::Ptr config = KSharedConfig::openConfig() );
    ~Config() override;
...

And then you call the usual function:

new Config(KSharedConfig::openConfig("myappconfigrc", KConfig::SimpleConfig, QStandardPaths::AppConfigLocation));

Now enjoy your configuration file living in it’s own directory! Here’s the constructor parameter logic in KConfig which was essential in figuring this out.

Welcome to the first "Codevis Weekly Update"

What is Codevis?

Codevis is a tool to help developers manage large codebases, sponsored by Bloomberg, developed by Codethink and hosted on the KDE Infrastructure, with all that, completely opensource with a permissive license. Codevis uses a mix of technologies to do what it does, mainly LLVM and Clang to do the heavy lifting of understanding C++ Codebases, Qt for Callback management (in the form of Signal/Slots), KDE Frameworks libraries for the desktop application, and pure Qt for the CLI application. The database layer is written with Soci , the same database layer used in CERN, targeting sqlite3.

But How does it work?

Codevis analyzes all the visible source code from your project and creates a graph database (using a relational database) in a way that the analyst can load and interpret information from the codebase without loading the codebase. The graph-database is comprehensive, and has all the information we think it's important, and also a lot of information that's good to have, with a bunch of information because why not. Since something that's not important for me could be really important for a company with billions of lines of code.

It just generates visualization?

No. Codevis also allows you to draw your software architecture and generate ready-to-compile c++ code from it. Think of this as a possibility to have C++ templates for complex projects tha are also visually documented. You can create libraries, classes, structures, connect them quickly on a dirty mockup during a meeting, and the output could be 60 c++ files on disk with all the classes, folder-hierarchy and CMake ready to compile.

This will not add any method or implement anything, but just the creation of the C++ files and CMake scripts from a small architecture meeting is pretty interesting in my point of view.

Contributing to KDE sometimes leads to a flood of negative or even insulting feedback. To not get disheartened by this it is important to correctly assess the significance of these comments. One possible stance to take towards these reports can be taken from punk culture.

I hope this video with hand-crafted subtitles will be a valuable resource for people stumbling into this situation in the future. Enjoy the skateboarding clips!

It's been a Long long time without posting anything. Not that i'm lazy (well, a bit). But I have been working on a lot of things related to KDE this past few years, and I was finally able to release and opensource Codevis. I know this post is as small as a tweet, just checking if the integration is stil working

Last weekend I went to the Linux Days in Voralberg (Austria) to host a booth with Tobias and Kai. It was hosted at the Fachhochschule (a sort of university for applied science) in Dornbirn and it was my first time attending this event.

Our booth was well visited and we had a lot of interesting discussions. As always, we had various pieces of hardware on our booth: 2 laptops, a Steam Deck, a Pinephone, a graphic tablet with Krita and two Konqi amigurumis.

Between booth duty, I still managed to watched one talk about open source deployment in public institutions in Baden Wurtenberg (a region/state in German). After the linux days, we all went to a restaurant and mass ordered Käsespätzle. Käsespätzle is a traditional food from this region and is made of cheese, Spätzle (noodles) and onions. It was excellent.

On Sunday, Tobias and I went to Golm with a local we met the day before. We took a gondola lift to reach a high-rope park in the mountains and then took an Alpine Coaster to go back in the valley. It was a lot of fun.

After our little adventure, we again went to eat in a traditional restaurant.

Here a few more pictures of the trip:

KStars v3.6.7 is released on 2023.10.03 for MacOS & Linux. Windows build is still pending and should hopefully be released by 10th of October. It's a bi-monthly bugfix release with a couple of exciting features.

Image Overlay Component

Rotator Dialog Improvements

More File Placeholders

Learning a language is, to me, about grinding. Continously exposing yourself.

Ich lerne Deutsch. Oder, ich versuche Deutsch zu lernen.

I try to expose my self to the language via YouTube (thx Nils for the tip about 7 gegen Wild), but also news papers and just chatting with people. I’d say the biggest hurdle is that people find English easier than having me try to find and reorder the words, so practice at full speed is hard to find.

I guess I do the same for people trying to learn Swedish, and i really shouldn’t.

If you have tips for how to expose myself more to German – spoken or written – please drop a comment here or join the conversation at mastodon.

A few days ago Volker Krause posted this blog about the Nextcloud conference - a very interesting read.

One of the topics is the VFS (Virtual Filesystem-) API for the Linux desktop. Indeed that is a topic for us at ownCloud as well, and I like to share our perspective on it, discussing it in the scope of the free desktop.

The topic is very important, as “syncing” of data from and to cloud storages has changed over time. From having all files mirrored from client to server and vice versa, it has now shifted to keep all files in the cloud, and have them as so called placeholders on the desktop. That means that most files on the client appear with size zero to save space, but the complete filesystem structure is available.

If a user starts to interact with such a dehydrated file, the content is of the file is downloaded transparently utilizing the cloud system client, for example ownClouds desktop client. The same happens when an application accesses such a file. As a result, the placeholders look and behave like the normal filesystem we are used to.

On Windows and on MacOSX, the problem is kind of solved. Both have added APIs to their OS that can be used to implement the access of data on the cloud.

On Linux, we do not have this kind of API yet. That means that it is close to impossible to implement this user experience. Volker already said that desktop environment specific solutions probably do not scale, which I agree with.

At ownCloud we have looked into the implementation of a specific FUSE file system. That should certainly be possible, and is probably a part of the solution, but is considerable effort because of the asynchronous nature of the topic. Given that the market share of Linux desktop systems is pretty small it is not attractive for companies to invest a lot into a Linux only system. Here the power of community could make a difference again.

It would be best if we as open source community would come up with a shared solution as a free desktop standard, that might be oriented on one of the existing APIs, maybe the MacOSX File Provider API: A library and little framework that the linux desktop environments can work with abstracting the VFS.

While collaborating on that, all data clouds could implement the bindings to their storage. With that, the extra implementation efforts for the Linux solution hopefully wouldnt be dramatic any more.

Let’s call this system openVFS as a work title. How can we evolve it? I’d like to invite all interested parties to discuss in this temporary Github repo to collect ideas and opinions. There is also a little experimental code.