KDE / Plasma config tracking issue

[deliciouslytyped]

Another stepping stone in my misguided Year of Nixfiguring the Linux Desktop... (see firefox issue)
This is placeholder content for the moment

[leinadlime]

@deliciouslytyped did you progress in this issue?
i am asking, also because i am interested in configuring KDE/Plasma....

otherwise I guess this can be closed...

[deliciouslytyped]

Not really, but I don't see why it should be closed.

[bew]

Hello,

I've found that using kwriteconfig5 it is possible to change any value in the config files (in ~/.config/*rc)
For example I can disable auto screen locking with:

kwriteconfig5 --file ~/.config/kscreenlockerrc --group Daemon --key Autolock false

I'm not sure if running this needs a reload of some kind, I checked that when I open the screenlock settings (with kcmshell5 screenlocker) the setting is indeed changed, but I suspect the settings app to re-read the config file, not take the runtime config.

Another one is ~/.config/powermanagementprofilesrc with the configs for power management based on various profiles: AC vs Battery vs Low battery.

# Configs for screen-dim & screen-off can be turned off completely by DELETING the keys:
RCFILE=~/.config/powermanagementprofilesrc
kwriteconfig5 --file $RCFILE --delete --group AC --group DPMSControl --key idleTime
kwriteconfig5 --file $RCFILE --delete --group AC --group DimDisplay --key idleTime
# same can be done for top groups Battery & LowBattery (instead of AC above)

As you can see, some options must be set to other values (like Autolock), or deleted (like idleTime) to change/disable them.

These were found by trial and error by opening the corresponding setting panel, changing an option and reloading the config file in my editor to see what changed.

So I think we could definitely write a home-manager module for configuring some parts of KDE at least.

---

FYI here are the config files (and their length in line count, bigger is usually more relevant) in my ~/.config:

$ wc -l *rc | sort -nr
  900 khotkeysrc
  255 kglobalshortcutsrc
  178 plasma-org.kde.plasma.desktop-appletsrc
   51 powermanagementprofilesrc
   28 ksmserverrc
   15 plasmashellrc
   15 konsolerc
   12 kxkbrc
   11 dolphinrc
   10 kwinrc
   10 ksysguardrc
    8 kscreenlockerrc
    6 kcmsambarc
    5 kactivitymanagerd-statsrc
    5 kactivitymanagerdrc
    4 ktimezonedrc
    4 kinfocenterrc
    3 kcminputrc
    2 powerdevilrc
    2 plasma-localerc
    2 kwinrulesrc
    2 krunnerrc
    2 kmixrc
    2 kded5rc
    2 kcmshell5rc
    2 kateschemarc

# additional files
$ wc -l plasma-nm
4 plasma-nm

[peterhoeg]

I have a very rough module that I've been using this locally for some time that somebody is very welcome to build on. I used to call kwriteconfig5 but instead of having a binary called a million times, I instead use crudini to merge ini files.

The module (incl bits that were started but not finished):

{ config, lib, pkgs, ... }:

with lib;

let
  cfg = config.programs.kde;

  baseDir = "plasma-workspace/env";

  # TODO: this isn't done yet
  environmentFile = pkgs.writeScript "10-environment.sh" (lib.concatStringsSep "\n" (lib.mapAttrsToList (k: v:
    ''# export ${k}="${toString v}"''
  ) (config.home.sessionVariables // config.programs.bash.sessionVariables)));

  settingsFile = pkgs.writeText "50-kde-settings.sh" ''
    ${cfg.scriptHeader}

    # extraSettings
    ${cfg.extraSettings}

    # settings
    for f in ${lib.concatStringsSep " " (lib.attrNames cfg.settings)}; do
      _msg "Processing: $f"
      ${lib.getBin pkgs.crudini}/bin/crudini --merge \
        ${config.xdg.configHome}/$f < \
        ${etcDrv}/etc/$f || true
    done
  '';

  actualFiles = [
    { sequence = "01"; name = "peterpeter"; contents = "# hello world"; }
    { sequence = "10"; name = "woot"; contents = "# bar"; }
  ] ++ cfg.files;

  etcDrv = pkgs.stdenv.mkDerivation {
    pname = "kde-settings";
    version = toString (builtins.length (lib.attrNames cfg.settings));

    buildCommand = lib.concatStringsSep "\n" (lib.mapAttrsToList (k: v:
      "install -Dm444 ${pkgs.writeText k (lib.generators.toINI {} v)} $out/etc/${k}"
    ) cfg.settings);
  };

in {
  meta.maintainers = with maintainers; [ peterhoeg ];

  options = {
    programs.kde = {
      enable = mkEnableOption "KDE";

      scriptHeader = mkOption {
        default = "";
        description = "Extra settings added to the top of scripts.";
        type = types.lines;
      };

      extraSettings = mkOption {
        default = "";
        description = "Extra settings added verbatim.";
        type = types.lines;
      };

      settings = mkOption {
        default = {};
        example = literalExample ''{ kwinrc = { General.Foo = "bar"; }; }'';
        description = "KDE settings";
        type = types.attrs;
      };

      files = mkOption {
        default = [];
        description = "The files we write.";
        type = types.listOf types.attrs;
      };
    };
  };

  config = mkIf cfg.enable {
    # xdg.configFile = builtins.listToAttrs (e:
    #   lib.nameValuePair
        
    # ) actualFiles;
    #   target = "${baseDir}/${toString e.sequence}-${e.name}.sh";
    #   text = e.contents;
    # }) actualFiles;

    xdg.configFile."${baseDir}/${environmentFile.name}".source = environmentFile;
    xdg.configFile."${baseDir}/${settingsFile.name}".source = settingsFile;
  };
}

and here is an example of how you would use it:

programs.kde.settings = {
      katerc = {
      "KTextEditor View" = {
        # input mode 1 is Vi, 0 is normal
        "Input Mode" = 0;
        "Vi Relative Line Numbers" = true;
      };
    };

    kdeglobals = {
      General.BrowserApplication = "firefox.desktop";
      KDE.SingleClick = false;
      # time/date
      Locale = {
        Country = "sg";
        TimeFormat = "%H:%M:%S";
        WeekStartDay = 1;
      };
    };
};

[bew]

Interesting solution @peterhoeg ! However the plasma files are not always exactly ini files.
For example this section is extracted from powermanagementprofilesrc :

[AC][HandleButtonEvents]
lidAction=0
powerButtonAction=16
triggerLidActionWhenExternalMonitorPresent=false

The "kind of" nested ini section breaks crudini's parser 😕

[peterhoeg]

The "kind of" nested ini section breaks crudini's parser 😕

Correct, that's why I have the extraSettings part in which I call kwriteconfig5 directly for the couple of files that are not proper ini files: extraSettings = '' # these files have weird nested stuff that crudini doesn't like, so do it here kw kscreenlockerrc --group Greeter --key WallpaperPlugin "org.kde.potd" kw krunnerrc --group General --key FreeFloating --type bool false ''; This is definitely not a proper solution. I like the ini merging bit because it means having all the customizations in a single derivation which is nice when you want to compare the changes to the actual file. So as you can see there are several reasons why this hasn't been submitted upstream.... It's hacky but it works for me. It would of course be great with a proper module!

[deliciouslytyped]

I just got some ideas on what to search for and found some things;

https://techbase.kde.org/Development/Tutorials/Updating_KConfig_Files
https://api.kde.org/frameworks/kconfig/html/kconfig_compiler.html
https://api.kde.org/frameworks/kconfig/html/
Also QT's QSettings might be relevant but I didn't check
https://develop.kde.org/docs/configuration/ -> https://develop.kde.org/docs/configuration/kconfig_xt/

There's probably some stuff I missed but XT looks very relevant;

The main idea behind KConfigXT is to provide a more convenient way to manage your application’s configurations for both for developers and system administrators who manage large KDE installations.

[peterhoeg]

kcondig is the framework that KDE applications use to handle configuration data (essentially what ends up writing the files in ~/.config/foorc). It doesn't do anything to help us with this the way I read it.

[leo60228]

@peterhoeg kconfig includes a tool to apply "updates" to config files. It's intended for changes in configuration files during program updates, but it seems useful for home-manager as well.
Running ${pkgs.kdeFrameworks.kconfig.out}/libexec/kconf_update kconf.upd with this kconf.upd will merge all keys from ~/.config/hm_kglobalshortcutsrc into ~/.config/kglobalshortcutsrc:

Version=5

Id=hm_kglobalshortcutsrc
File=hm_kglobalshortcutsrc,kglobalshortcutsrc
Options=copy,overwrite
AllKeys
Options=copy,overwrite
AllGroups

This format is more powerful, and can do things like run scripts to mutate configuration files using an stdin/stdout-based IPC API and delete keys: https://techbase.kde.org/Development/Tools/Using_kconf_update

[peterhoeg]

Wasn't aware of that, thanks but a couple of points from a cursory glance: 1. kconf_update path: ${lib.getLib libsForQt5.kdeFrameworks.kconfig}/libexec/kf5/kconf_update 2. kconf_update tracks state both using the updated file (in update_info) as well as its own state file kconf_updaterc 3. it doesn't unconditionally apply updates unless we start fiddling with the saved state info which looks error prone and possibly interferes with actual config updates we receive from upstream

[leo60228]

For what it's worth, this tracking is based on the filename, meaning if the store hash is different the update will be reapplied.

[leo60228]

kconf_update is relatively small, it might be worth making a modified version optimized for home-manager's purposes: https://github.com/KDE/kconfig/tree/master/src/kconf_update

[peterhoeg]

My understanding is that the tracking is based on id, not source file name but we could set the id to the store path. That being said, I can't quite work out if the tracking is a good or bad thing in our case as the change isn't being applied all the time, which may be what we want. The difference between using hm to set defaults or enforce a particular setting. But sure, one could fork it.

[leo60228]

I've checked and it seems to be the store path.

[stale]

Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

• If this is resolved, please consider closing it so that the maintainers know not to focus on this.
• If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

• If you are also experiencing this issue, please add details of your situation to help with the debugging process.
• If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

If you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information.

Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[deliciouslytyped]

How about no.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/declarative-kde-configuration/15901/7

[kurnevsky]

Here what I did in case somebody finds it useful: https://github.com/kurnevsky/nixfiles/blob/master/modules/kde.nix

[pjones]

Hello all. I've used the ideas from @bew and @kurnevsky to create a standalone project: Plasma Manager.

I would love contributions and feedback from those that are interested. My eventual goal is getting this moved into nix-community, or if it makes sense, home-manager.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-to-configure-kde-properly-in-nix/21362/4

[ShalokShalom]

Considering plasma-manager has advanced to become a serious tool for this job, can we consider to a) move it to nix-community, and b) close this issue?

[kurnevsky]

Considering plasma-manager has advanced to become a serious tool for this job

Btw, does it work correctly for plasma 6? I was a bit scared to use it because it contains a lot of things that easily can change with plasma update. And for instance, configs for hotkeys changed in plasma 6 so that my config was broken.

Added: looks like it should be fixed: nix-community/plasma-manager#24

[ShalokShalom]

I just read that just dumping a config file somewhere in XDG_CONFIG_DIRS works now for most things, so all of the kwriteconfig hacks should not be needed any more.

It seems much easier now.