KDocker 6.0 Released

Introduction

It’s finally here, KDocker 6.0. It’s the biggest since release ever and packs in every one of my wishlist features. While there are a lot of changes, I want to talk about a few of the more important and interesting ones.

Updates

First and foremost, it’s been updated for Qt 6. KDocker’s major versioning since 4.0 has followed the major Qt version it uses. With Qt 6.7 being the current release it’s plenty stable and Qt 6 has wide distro availably.

Next up, the project has finally outgrown QMake and is now using CMake as the build system. One benefit is being able to specify the install location as part of configuration. With QMake you had to edit the .pro file.

Code wise, every file was touched in some way. Probably, half the code was rewritten. This release is a full modernization up to C++17 standards. I think. At least I tried to get it all up to the 17 standard. That said, there was a lot of work put into modernizing and updating the code.

There are all new icons! Both the menu and application have been replaced with more modern looking ones. They, dare I say, look better than the old ones. Also, all menu items have icons so there are no gaps like in previous releases.

Command line options were overhauled both with how they’re processed and what they can do. Long options are now supported which has been a surprising ask from multiple people. The name (title) matching option was the most impacted. It’s now takes a PCRE regular expression. As such the helpers, -e, -j, and -k have all been removed due to them being modifiers needed to work around the limited matching support in previous KDocker versions.

Packages

In addition to the source archive release, I’m now building Snap and Flatpak packages. That said, I recommend installing from source due to limitations of these packaging systems. Neither provides KDocker’s full functionality.

Both package formats have pretty strict isolation of the application from the rest of the system which impacts KDocker. Sandbox isolation is a feature, not a bug, of these package systems.

A major feature of KDocker is launching other applications and it’s the main way I see people use KDocker. Being able to run arbitrary applications outside of the sandbox is an escape that defeats the security model provided by these pacakge systems.

Snap

Snap’s isolation prevents KDocker from launching other applications. However, I’ve worked around this by using ‘classic’ confinement. This isn’t ideal because using this level is discouraged. Getting it into the Snap store could be a challenge due to needing manual approval to use that level.

Another limitation of Snap packages is the inability to use DBus auto start. Snap does not allow auto starting on the session bus. Thus, this feature is not present when installing via Snap. Use the --keep-running option when starting KDocker if you plan to interact with it via DBus.

Flatpak

There isn’t a work around for Flatpak’s isolation, because it’s not something that should have a work around in the first place. It’s part of the security model after all. So application launching just doesn’t work if installing via Flatpak.

KDocker will not keep running when the last window is closed when using the --keep-running option if installed as a Flatpak. However, this option shouldn’t be needed because DBus auto start works with the package. Also, this only applies if accessing KDocker via DBus.

Distribution

Right now KDocker is not published to the Snap and Flatpak repos. This may change in the future but, right now, I don’t distributing with limited functionality is the right call. Especially, when each has different limitations and give a sub par experience.

I may not even attach the packages to the GitHub release.

DBus

I’ve been wanting to support a DBus interface for a long time and now it’s finally happened. This has been on my wish list since 5.0 but back then DBus wasn’t as widely adopted so I was hesitant to support it.

Today, DBus is basically required for modern desktop Linux. Both KDE and Gnome use it extensively. Even systemd can use DBus. Therefore, I’m now comfortable using and requiring it.

Single instance

Previously, KDocker was using the Qt solution, QSingleApplication to function as a single instance application. It’s a good solution and if your application is multi-platform it works well. KDocker isn’t multi-platform so it be replaced with another option. DBus.

When KDocker starts it attempts to registers itself with the session bus. If it can’t register, then another instance is already running and that one is forwarded the request. It’s that easy to create a single instance application with DBus.

Manage interface

A common request I’ve gotten is a way to script interactions with KDocker. Previously, the only real scripting that could be done was when launching or docking an application. That’s great but only one use case.

With DBus I’m able to expose a number of different operations. Every docking operation, select, focused, launch, match, window id, and process id, can all be run via DBus.

Also, there are methods exposed to control docked windows. For example, hide, show, and undock are available. You can even quit KDocker from DBus. More can be added in the future but right now the most common use cases are covered with what’s there.

Auto start

DBus will auto start KDocker if the interface is used and KDocker is not running. This is a very handy feature because anything scripted does not need to check if KDocker is already running and launch it. This is handled as part of DBus’ service activation system.

Final Thoughts

What started with me wanting to do a quick update to Qt 6 spiralled into something bigger. A major overhaul was not what I intended but it’s what happened and I’m happy it did. Overall, I’m very pleased with how this release turned out and everything I’ve been able to pack into it.