KDE Ni! OS is a custom flavour (configuration, not a separate distribution) of NixOS that showcases KDE software. It builds on NixOS with the aim to reimplement the same features other popular immutable distributions have, while providing a first-class KDE Plasma setup.

The Plasma Login Manager support has been merged into Ni! OS.

If you want to use it, there are two prerequisites:

1. you are using Wayland, not X11; and
2. you are on unstable NixOS.

It is in the “works for me” state. I don’t use auto-login, virtual keyboard, etc.

Going unstable

If you are on the stable channel, which would surprise me as you’re reading this post, it is easy to switch to unstable just by running these commands as root user (sudo, or su, or…).

nix-channel --add https://channels.nixos.org/nixos-unstable nixos
nix-channel --update
nixos-rebuild switch --upgrade 

This will switch you to the unstable version of NixOS.

Mind that, as NixOS is an immutable distribution, you can easily boot back into the stable version – the previous version of your system is still accessible in the bootloader menu.

Switching from SDDM to the Plasma Login Manager

There’s a new option in Ni! OS called experimental.use_plasma_login_manager. The only thing you need to do in order to switch from SDDM to the Plasma Login Manager is to set it to true, and just switch your setup to the new configuration with:

nixos-rebuild switch

Switching back is also trivial – just change the value back to false and do the switch again.

There and back again

One new thing in Ni! OS is a custom label for the versions of the system (derivations in NixOS terminology).

If you enable an experimental feature such as the Plasma Login Manager, the label will clearly denote that. It makes it easy to get back to a version without the experimental features enabled.

As you can see in the following screenshot, the default label is kde-ni-os and all enabled experimental features are appended to it – when enabling the Plasma Login Manager, the label becomes kde-ni-os:plasma-login-manager. These labels can be seen in the following screenshot:

[edit] Upstream

Was notified by NixOS KDE maintainer K900, that PLM will officially become a part of nixpkgs as Plasma 6.5.5 gets updated to 6.6.

You can follow the progress of the patch here.

Once Plasma 6.6 is released, and it becomes available in nixpkgs, Ni! OS will start using the official package instead of my local hack.

KDE Ni! OS is a custom flavour (configuration, not a separate distribution) of NixOS that showcases KDE software. It builds on NixOS with the aim to reimplement the same features other popular immutable distributions have, while providing a first-class KDE Plasma setup.

Just a teaser this time.

I’ve read somewhere that Fedora will be the first distribution to replace SDDM with Dave’s brand new Plasma Login Manager.

Will Ni! OS be the first non-distribution to do the same?

And if it does, will it become a distribution as it distributes yet another package not available in vanilla NixOS? :)

KDE Ni! OS is a custom flavour (configuration, not a separate distribution) of NixOS that showcases KDE software. It builds on NixOS with the aim to reimplement the same features other popular immutable distributions have, while providing a first-class KDE Plasma setup.

This post will show the NixOS way of adding a custom package and explain the benefits of this approach in the context of system immutability.

Plasma Pass

KDE Ni! OS recently got a new package installed by default – Daniel Vrátil’s Plasma Pass applet.

Plasma Pass is a Plasma applet to access passwords from pass, the standard UNIX password manager. You can find more information about the applet in Dan’s blog post.

As NixOS doesn’t currently offer Plasma Pass in its repositories, the package is installed in Ni! OS from the sources as in some other BTW, I use … distributions.

In NixOS, this is easily done via overlays. We can create an overlay that defines the plasma-pass package so that it can be installed as if it were a real NixOS package.

Package definition

This is the overlay definition used in Ni! (ni/packages/plasma-pass.nix):

self: prev: {
  kdePackages = prev.kdePackages.overrideScope (kdeSelf: kdeSuper: {
    plasma-pass = kdeSelf.mkKdeDerivation rec {
      pname = "plasma-pass";
      version = "1.3.0-git-59be3d64";

      src = prev.fetchFromGitLab {
        domain = "invent.kde.org";
        owner = "plasma";
        repo = "plasma-pass";
        rev = "59be3d6440b6afbacf466455430707deed2b2358";
        hash = "sha256-DocHlnF9VJyM1xqZx/hoQVMA/wLY+4RzAbVOGb293ME=";
      };

      buildInputs = [
        kdeSelf.plasma-workspace
        kdeSelf.qgpgme
        self.oath-toolkit
      ];

      meta = with prev.lib; {
        description = "Plasma applet for the Pass password manager";
        license = licenses.lgpl21Plus;
        platforms = platforms.linux;
      };
    };
  });
}

Most of this file is self-explanatory (except for the strange looking syntax of the Nix language :) ).

Since Plasma Pass is a KDE project, we want it visible as a part of kdePackages collection, and as it uses the common build setup that all KDE projects use (or should use), it uses mkKdeDerivation to define the plasma-pass package. This defines some basic dependencies, commonly used by KDE projects and adaptations needed for them to work properly in NixOS. For non-KDE-friendly packages, you’d base your package on the standard mkDerivation instead.

The project sources are located on the KDE’s GitLab instance at invent.kde.org, therefore the package definition uses fetchFromGitLab to retrieve the sources. It is also possible to clone repositories on GitHub, fetch and use source tarballs, etc. All fetchers are described at NixOS Manual > Fetchers.

The rev field in the fetchFromGitLab command is the GIT revision that you want to install, and hash you can get by using the nix-prefetch-git command:

nix shell nixpkgs#nix-prefetch-git
nix-prefetch-git https://invent.kde.org/plasma/plasma-pass \
    --rev 59be3d6440b6afbacf466455430707deed2b2358

The buildInputs part defines additional dependencies needed by Plasma Pass, and meta defines some meta information about the package such as the description and the license.

Using the definition

After defining the package, we have to add it to nixpkgs.overlays in any of our NixOS configuration files. In the case of Ni! OS, this is done in ni/modules/base.nix which defines the UI software that Ni! OS installs by default.

nixpkgs.overlays = [
    (import ../packages/plasma-pass.nix)
  ];

With this overlay, plasma-pass can be used as if it was a normal NixOS package.

environment.systemPackages = with pkgs; [
  ...
  kdePackages.plasma-pass
  ...
  ];

When plasma-pass gets added to the nixpkgs repository, the only action that will be needed in Ni! OS to switch to the official version is to remove the import...plasma-pass.nix from the overlays (this is the reason why we explicitly placed it in kdePackages collection – otherwise, we could have just put it top-level).

Custom packages and immutability

The main point of this post is not really to announce that a single new package is added to the Ni! OS setup. Even if it is a cool one like Plasma Pass.

The point is to show how a custom package that is not available in the vast collection of nixpkgs can be added to a NixOS-based system.

The custom package becomes a proper regular Nix package and gets all the benefits of Nix’s particular approach to immutability. If Plasma Pass gets broken after an update (either if new Plasma version breaks Plasma Pass, or if the new version of Plasma Pass no longer works as expected), you can always boot into the version before the bad update.

With distributions with immutable core and custom applications installed as Flatpaks, downgrading is possible, but a bit more involved and relies on 3rdparty keeping the old package versions still available for download.

With NixOS, all the previous versions remain on your system until you decide to remove them.

As a reminder, KDE Ni! OS is not a distribution, but a configuration for NixOS that aims at providing a ready-made immutable system for KDE users and developers with similar features to those of proper immutable KDE distributions.

If the Google search AI tells you it is a distribution, do not trust it:

Further, if the Google search AI tells you Ni! OS is a code name for KDE Linux, do not trust it:

Repository

The project got a repository at invent.kde.org which is currently in a very rough/bare state. Could be useful to existing NixOS users, but has a long way to go to become a proper resource on how to install and use Ni! OS.

Logo

NixOS has its own (quite cool, if you ask me) logo which doesn’t suite the comical image Ni! OS is trying to achieve.

For this reason, Ni! OS now has a proper custom logo – representing a – a shrubbery! – one that looks nice, and not too expensive.

It is also meant to represent the way NixOS achieves immutability. Many packages are present on the system, but hidden from the plain sight as they belong to the previous system versions or are just hidden-from-the-user dependencies of other packages.

Things shouldn’t come in twos. There needs to be another immutable KDE distro, so I’m announcing the …

Now, this is a bit of a joke.

This is not really going to be a new distribution (for real, not like KDE Neon claimed not to be a distribution back in the day :) ). I don’t have the expertise nor the time to make a distribution from scratch.

But, while listening to the presentations about KDE Linux and KDE Neon Core, I had the idea to see how many of the planned features for those distributions I could implement based on an already existing and quite popular distribution called … if you have a keen eye, you might have guessed based on the image above … NixOS.

Step 1: Immutability

At the crux of it, immutability (along with other related buzzwords) means that you can not have an update break your system. There are no half-updates, no mixing incompatible versions of packages, etc. And if something gets broken with the new version, you can always roll back your system to a previous version.

This comes out of the box with NixOS. It just does it in a different way to other distributions. Its package manager allows installation of as many versions of a single package as needed, and the user or a running application “sees” only the versions they are compatible with.

When you update your system, the old packages are still installed, and you can reboot the computer into the pre-update state (previous versions are called generations).

Booting into an old state doesn’t really do anything special, it just makes you “see” the versions of the packages that were active in that version of your system. You don’t even need to reboot most of the time – if you see that a new version of LibreOffice doesn’t open your file correctly, and you want to try with the previous version, just ask Nix to launch the old version for you. The old version of LibreOffice is still on your system even if you’ve not booted into the system version (generation) it was installed on.

Steps 2..n

My main computer is (and always will be) Debian, but I’ve been using NixOS on my laptop for months now. And it works quite well.

As NixOS can be installed or replicated from a single configuration file, I plan to create a repository that will hold the definition of the system on my laptop (aka, the reference installation of KDE Ni! OS :) ) and to keep it updated while I go through each of the steps of simulating other distributions’ features.

This way, anyone who wants to have KDE Ni! OS on their computer will be able to install it by installing NixOS and using this file for system definition.

The next step will mainly be for developers – it will be about replacing a system package with a version you (or somebody else) developed. For example, if you want the Plasma Vault to behave a bit differently, or to test a fix for a bug you found, any sane distribution should allow you to do that easily, and without endangering the system integrity (no sudo make install). So, KDE Ni! OS will have to be able to do it as well.

I had to abandon and open new PRs a few times now because of this.

Something like this is easy to check on the client side with pre-commit hooks. (a pre-push hook can also be used, but I like the check to be as early as possible)

A simple hook script that checks your branch name starts with work/YOUR_USER_NAME (I like to have the username in the branch name) is rather simple to write:

#!/bin/bash

REPO_URL=$(git remote get-url origin)
KDE_REPO_HOST="invent.kde.org"

if [[ "${REPO_URL}" == *"${KDE_REPO_HOST}"* ]]; then

    BRANCH=$(git rev-parse --abbrev-ref HEAD)
    BRANCH_REGEX="^work/$USER/.*$"

    if ! [[ $BRANCH =~ $BRANCH_REGEX ]]; then
      echo "Your commit was rejected due to its name '$BRANCH', should start with 'work/$USER'"
      exit 1
    fi

fi

It checks that the Git repository is on invent.kde.org, and if it is, it checks if the current branch follows the desired naming scheme.

KDEGitCommitHooks

But the question is where to put this script?

Saving it as .git/hooks/pre-commit in the cloned source directory would work in general, but there are two problems:

• Manually putting it into every single cloned KDE source directory on your system would be a pain;
• KDEGitCommitHooks, which is used by many KDE projects, will overwrite the custom pre-commit hook script you define.

The second issue is not a problem since a few hours ago. KDEGitCommitHooks (a part of the extra-cmake-modules framework) now generates a pre-commit hook that, additionally to what it used to do before, executes all the custom scripts you place in the .git/hooks/pre-commit.d/ directory.

So, if a project uses KDEGitCommitHooks you can save the aforementioned script as .git/hooks/pre-commit.d/kde-branches-should-start-with-work.sh and it should be automatically executed any time you create a new commit (after KDEGitCommitHooks updates the main pre-commit hook in your project).

For projects that do not use KDEGitCommitHooks, you will need to add a pre-commit hook that executes scripts in pre-commit.d, but more on that in a moment.

Git templates

The first problem remains – putting this into a few hundred local source directories is a pain and error-prone.

Fortunately, Git allows creating a template directory structure which will be reproduced for any repository you init or clone.

I placed my template files into ~/.git_templates_global and added these two lines to ~/.gitconfig:

[init]
    templatedir = ~/.git_templates_global

I have two KDE-related hook scripts there.

The above one is saved as ~/.git_templates_global/hooks/pre-commit.d/kde-branches-should-start-with-work.

And the second file is the default main pre-commit (~/.git_templates_global/hooks/pre-commit) script:

#!/usr/bin/env bash

# If the user has custom commit hooks defined in pre-commit.d directory,
# execute them
PRE_COMMIT_D_DIR="$(dirname "$0")/pre-commit.d/"

if [ -d "$PRE_COMMIT_D_DIR" ]; then
    for PRE_COMMIT_D_HOOK in "$PRE_COMMIT_D_DIR"/*; do
        ./"$PRE_COMMIT_D_HOOK"
        RESULT=$?
        if [ $RESULT != 0 ]; then
            echo "$PRE_COMMIT_D_HOOK returned non-zero: $RESULT, commit aborted"
            exit $RESULT
        fi
    done
fi

exit 0

It tries to run all the scripts in pre-commit.d and reports if any of them fail.

This default main pre-commit script will be used in projects that do not use KDEGitCommitHooks. In the projects that do, KDEGitCommitHooks will replace it with a script that executes everything in pre-commit.d same as this one does, but with a few extra steps.

There are some Bash and Zsh scripts that allow you to have separate histories for each directory you’re in which can be useful in situations such as these, but the issue is that you get separate histories for each directory instead of for each project. This means that you would get one history when you are in project’s root directory, and another when you’re in some subdirectory of said project.

For this reason, I’ve created a small Zsh plugin based on jimhester/per-directory-history.

Instead of creating a separate history for each directory you change to, it creates separate histories only for directories that are ‘tagged’ with some custom file, be it .git, .envrc or something else (it is customizable).

For any directory you change to, it will check if that directory or any of its parents (it will search for the closest parent) contain the ‘tag’ file and it will use that directory as the project root thus creating a separate history for it.

Installation and configuration

You just create an array named PER_PROJECT_HISTORY_TAGS that contains all the file names you want to be used for detecting the project roots:

declare -a PER_PROJECT_HISTORY_TAGS
PER_PROJECT_HISTORY_TAGS=(.envrc .should_have_per_project_history)
declare -r PER_PROJECT_HISTORY_TAGS

In the example above, any directory that I defined custom environment variables for using direnv’s .envrc will be treated as project roots, along with any directory explicitly tagged with .should_have_per_project_history.

This is useful when you have several source repositories inside of a single project that should all have a common history, so you can’t use .git as a tag to detect the project root.

If you don’t define your own tags, the default ones will be used (.git .hg .jj .stack-work .cabal .cargo .envrc .per_project_history).

Then you just source the per-project-history.zsh file from the plugin’s repository.

Or, if you use a plugin manager, add ivan-cukic/zsh-per-project-history to the list of plugins. For Zinit, it would look like this:

zinit light ivan-cukic/zsh-per-project-history

Now, I tend to redefine most of the default shortcuts, so this didn’t affect my workspace directly, but I liked the idea to have different modifiers used depending on the category of /thing/ for which I’m creating a shortcut.

An additional aim I had is to have a common shortcut ‘body’ for equivalent actions in different categories, in order to more easily build muscle memory with my new shortcuts.

Categories that I have are:

1. system (Plasma and such)
2. terminal application (Konsole, Kitty)
3. terminal multiplexer (TMux)
4. specific application (Firefox, Vim, …)

And these are the modifiers I’m trying out:

1. system: Meta+Anything and Alt+Special keys
2. terminal application: Ctrl+Shift+Anything
3. terminal multiplexer: nothing special yet, just the Ctrl+d as the leader
4. specific application:
   • working with tabs: Ctrl+Anything
   • other shortcuts: Alt+Normal keys

So, for example, the ; and ' as the shared shortcut /bodies/ mean the following in different categories:

1. Meta+; and Meta+' – switch to next and previous window (I’m using Krohnkite for tiling, so this is not like Alt+Tab, but moving through the visible tiled windows);
2. Ctrl+Shift+; and Ctrl+Shift+' – would mean switch to next and previous panes in the terminal application (I’m not using this yet, as I don’t tend to use split views in terminal except in TMux);
3. Ctrl+d ; and Ctrl+d ' – move to next and previous panes in TMux;
4. Alt+; and Alt+' – move to next and previous panes in an application (currently only in Vim and Neovim).

So far, the approach seems to work Ok. I’ve quickly got accustomed to the new window/pane navigation shortcuts.

The main problem are the programs that don’t allow changing shortcuts (Firefox for example) or don’t allow creating shortcuts with some key combinations (using Ctrl+; in Vim or Neovim does not work, while it works with Alt).

Because of those limitations, the modifiers are not as clear cut as they ideally would be. Ideally, each category would have its own single modifier, instead of, for example, having a mix of Alt and Ctrl in the /specific application/ category, and using a modifier combination like Ctrl+Shift for the /terminal application/.

I’ve also redefined all my Plasma and KWin shortcuts to be location-on-keyboard-based, but more on that later.

It activates a specific theme based on the project you are working on (the current directory you start Neovim from).

It allows you to define which themes should be used for which projects. The configuration is simple and allows specifying patterns for matching project names (not full regex, but what Lua supports).

My configuration looks something like this (this is in Fennel, for the Lua version, check out the readme):

:opts {
    :themes [
        { :matcher "radio" :theme "nordic" }
        { :matcher "^/kde" :theme "hybrid" }
        { :matcher "qt$"   :theme "moonfly" }
    ]
    :defaultTheme "habamax"
    :postExec {
        :moonfly [ ":hi TabLineSel guibg=#508050 guifg=#f0f0f0" ]
        :nordic  [ ":hi TabLineSel guibg=#5070f0 guifg=#f0f0f0" ]
        :hybrid  [ ":hi TabLineSel guibg=#80a020 guifg=#f0f0f0" ]
    }
}

The source code, and the instructions how to use it are available on GitLab.

EDIT: Paul’s repository has been updated to include fixes for Plasma 6.3, and the new version has been released.

You might have seen the awesome Klassy theme by Paul McAuley for Qt applications and window decorations for KWin.

It has some issues compiling against the latest Plasma since the KDecoration API break.

Until it is fixed in the main repository, I’ve created a temporary fork that includes the port to KDecoration3 done by Eliza Mason, with a tiny additional fix I added on top of it. The fork is available at github.com/ivan-cukic/wip-klassy

The kdesrc-build recipe for it is:

module klassy
    repository https://github.com/ivan-cukic/wip-klassy
    cmake-options \
        -DBUILD_QT5=OFF \
        -DBUILD_QT6=ON
    branch plasma6.3
end module

I’ve started working on some new artwork, and ended up sidetracked spending more time designing fun clocks for Plasma than on what I planned to work on, proving there’s some truth to the meme.

These are based on one of the coolest watch designs I’ve seen in recent years – a Raketa Avant Garde:

I’ve noticed that I don’t update them as often as the rest of the system, so I decided to see if I can add them to kdesrc-build.

The packages-to-be-built definitions are located in repo-metadata/module-definictions which already contains a few 3rd-party libraries that the KDE frameworks and applications use.

Adding the Strawberry player (fork of Clementine, which was a fork of Amarok 1.x) to the build, was quite straight-forward. I just needed to define the repository, cmake options to make it build the Qt6 version instead of the Qt5 one, and the branch I want to build from.

module strawberry
    repository https://github.com/strawberrymusicplayer/strawberry.git
    cmake-options -DBUILD_WITH_QT6=ON
    branch master
end module

For applications with normal cmake setup, it is as easy as that. But there are applications like recoll which don’t have a CMakeLists.txt file in the top level, and kdesrc-build doesn’t like that.

To ensure that kdesrc-build finds the real src directory for cmake, I needed to do something completely hackhish. I had to pass the path to the source directory, which is otherwise defined automatically by kdesrc-build for each project it builds, to cmake-options:

module recoll
    repository https://framagit.org/medoc92/recoll.git
    cmake-options \
        -DRECOLL_QT6_BUILD=1 \
        -DRECOLL_ENABLE_SYSTEMD=0 \
        -DRECOLL_ENABLE_WEBENGINE=1 \
        -DRECOLL_ENABLE_X11MON=0 \
        -S /kde/src/recoll/src
    branch master
end module

Fortunately, kdesrc-build appends cmake-options the normal cmake arguments, so my -S path overrides the path that kdesrc-build defines.

There was a call for artwork for the next Debian release – Trixie, and I made a modified version of one of my old wallpapers for it. As it was not chosen to be the default in Trixie, I decided to post it here for people who might like it.

It is, like all my wallpapers, a calm non-distracting one. (it is much prettier full-4k-size than in the thumbnail below)

If you like it, you can download it from Debian’s Wiki – in 1920x1080 and 4k versions. There is also a version with the Debian logo there for inspiration if you want to create a custom distribution-branded one.

Some time ago, there was a controversy regarding the Floorp web browser (a fork of Firefox) going closed source.

The cause for this was that some company forked Floorp and made a browser based on it. I’ll not comment on the irony that the author of a fork of a project complained that someone forked his project.

Obviously, this triggered a storm of negative reactions on quite a few platforms where fans of Free Software / Open Source software hang out.

The developer responded that this is just temporary, and that the browser will soon be Open Source again. After a while, the repositories became public again and all was fine.

The developer said that Floorp is again Open Source, the angry mob said good, the Floorp browser is again Open Source. And every discussion about Floorp got a plethora of comments that people should stop complaining, that Floorp is Open Source, and that the previous situation was just a misunderstanding.

Open Source

The term Open Source is well defined at opensource.org.

Making the source code of a program publicly available is not enough for something to be Open Source. Having an army of people saying that something is Open Source, is not enough for something to be Open Source.

If a license that the code is published under doesn’t conform to the criteria published on opensource.org, a program is not Open Source. A program whose license contains the following sentence, is, by definition, not Open Source:

You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, or distributing the Software for use with commercial products.

– Floorp private components/LICENSE

This is strangely worded as it looks like you can not use the Floorp web browser to access, for example, a work e-mail account as that would be using it for commercial purposes. This is likely not what the license author intended – the intent of the license is to disallow creating commercial products by forking Floorp.

While it is a valid desire of the author not to have somebody else profit from his work, it is the thing that makes the Floorp web browser not Open Source.

You can call it ‘source available’, you can call it ‘fair code’ but you can not call it Open Source.

Update: A few days after this blog was published, Floorp moved the code from the private submodule to the main repository. So, it should be again Open Source. Let’s hope it remains like that.

Redefining Open Source

This blog post should have been written when the Floorp thing happened, but I thought this is just a random incident not worth the extra attention.

It seems I was wrong. It is something that people should start paying attention to.

A lot of people – developers and users alike, intentionally or not – misuse the term Open Source, and some of them like FUTO even go that far to redefine it and create their own incompatible The Open Source Definition that will suit their own purpose.

Open Source Confusion Cases

Now, the main purpose of this post isn’t for me to let off some steam, but to share a great project started by Dan Brown of attempting to find and list all projects which claim to be Open Source while their licenses say otherwise.

It can be found on his Github account.

Share your views to FSFE

Albert pointed out that FSFE is also interested in this topic:

The FSFE is looking for examples and thoughts about openwashing if you feel like it I’m sure they’ll welcome your input mastodon.social/@johas/112524760073638652

This means that I need to have different icons shown in Plasma’s panel in order to be able to easily differentiate which profile a window belongs to.

Sure, I use the tasks applet which shows the window title instead of the icon-only one (I prefer usability to minimalism), but still, it isn’t enough as sometimes the active tab in a Firefox window might not have the most informative title.

Plasma seems to rely on the application name and the window class when choosing the icon it will show in the panel. Which means that, by default, all Firefox instances end up having the same icon.

Fortunately, Firefox allows you to specify the window class it should use through command line arguments.

firefox -P ProfileName --class WindowClassName

And, to connect a launcher to a specific window class, you just need to add the following line to the .desktop file:

StartupWMClass=WindowClassName

So, in order to have a nicely supported Firefox profile, you can create a launcher with a desktop file similar to the following:

[Desktop entry]
Exec=firefox -P SocialSites --class FirefoxSocialSites
Icon=user-available-symbolic
StartupWMClass=FirefoxSocialSites

It also works with Firefox derivatives such as Librewolf (which can be seen in the screenshot above) and others.

Wayland

For Wayland users, a comment by John Kizer might be useful:

On Wayland, I’ve ended up just using KWin Window Rules (based on a substring of the window title, and setting the desktop file name) in combination with .desktop files that launch Firefox to the site in question and have the desired icon associated.

EDIT: And another approach for Wayland by Christoph Martin:

There’s no need for messing around with window rules - at least not for Firefox.

If you use the –main flag instead of the –class flag for the Firefox invocation in your .desktop file, you should get the desired effect - at least in the Icons-Only Task Manager. Note that StartupWMClass still needs to match the value of the –main flag.

The above works on my machine, that is under Plasma 6.0.5 on the Fedora 40 KDE spin.

Credit: https://superuser.com/a/1784867

Unfortunately (?), one of the recent Debian updates broke Bismuth in Plasma 5.x as well, so I had nothing keeping me on the old version anymore. I’m now (again) running the development version of (most) KDE software.

Since the update, I managed to make the Qtile tiling window manager work with Plasma to some extent. But the integration between Qtile and Plasma I hacked was less than ideal, and I kept switching between KWin which worked perfectly, as KWin does, but without tiling, and my Frankenstein Qtile which didn’t work that well, but it had tiling.

Maybe I’ll write about it if I get back to hacking Qtile, but that might not happen any time soon because…

Krohnkite

Then I saw the news that the predecessor of Bismuth – the Krohnkite script has been ported to KWin 6 – see the announcement on reddit, github to get and review the code, and kde store for the package you can install.

Huge kudos to all who are involved in the rebirth, the script works as well as it did with KWin 5.

Window decoration

The only thing missing was the simple ‘just a line around the window’ window decoration that Bismuth had.

Now we have that as well, I’ve ported the original Bismuth window decoration to KWin 6 (nothing huge, just a few tiny changes to make it compile). The code, and the installation instructions are available on github.

For those who haven’t met SObjectizer before, it is a framework for writing concurrent applications which supports the actor model, publish-subscribe…

EDIT: The series are available on Marco’s blog as well as on dev.to