# The wish I would like to manage Plasma configuration via text files rather than the GUI. That way one could copy the text file to a new machine, as opposed to spending around an hour clicking through the Settings. One could even try out someone else's settings -- something that's not practical when it takes a lot of work to change them. # What doesn't work I tried blindly copying all my KDE config files once, and it broke Plasma. According to someone on the NixOS forum[1] that's to be expected, because KDE config files are a mix of human-readable and machine-generated text. # Scope A number of people on that NixOS forum wish for the same thing. There are a few other apps to which the same issue applies -- off the top of my head, Dolphin and Konsole. But at least for me, the lion's share of the configuration work for a new system is in configuring Plasma itself. I believe this applies to all versions of Plasma on all flavors of Linux. [1] https://discourse.nixos.org/t/declarative-kde-configuration/15901
Configuration is stored in text files (using INI format) in ~/.config. Can you please be more specific with what is causing problems? As-is this isn't really actionable
Thanks for responding so fast. Maybe this is all perfectly readable and human-editable and I just haven't found the documentation specifying how changes in the GUI map to changes in the configuration language. Is that the case? I wish I could modify those config files, or copy them (or passages from them) from elsewhere, and expect it to work. There are two reasons I currently can't: (1) I tried it and broke KDE. I had to reinstall my OS. I wish I could easily repeat variations on that experiment but I can't. (2) It's not clear which files to copy or modify, or where, or how. Where are the zoom settings kept? The language settings? The number and layout of desktops settings? The setting that swaps Capslock and Esc? If I grep for the word "shortcut" I only find this passage in `~/.config/plasma-org.kde.plasma.desktop-appletsrc`. I've configured a lot of shortcuts and none of them are here: ``` [Containments][2][Applets][3][Configuration][Shortcuts] global=Alt+F1 [Containments][2][Applets][3][Shortcuts] global=Alt+F1 ``` Searching for "desktop" is even harder to make sense of: ``` find . -iname "*plasma*" -print0 | xargs -0 grep -i desktop ./plasmashellrc:performed=/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/unlock_widgets.js,/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/systemloadviewer_systemmonitor.js,/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/maintain_existing_desktop_icon_sizes.js,/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/containmentactions_middlebutton.js,/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/obsolete_kickoffrc.js,/run/current-system/sw/share/plasma/shells/org.kde.plasma.desktop/contents/updates/move_desktop_layout_config.js ./plasmanotifyrc:[Applications][telegramdesktop] ./plasma-org.kde.plasma.desktop-appletsrc:wheel:Vertical;NoModifier=org.kde.switchdesktop ./plasma-org.kde.plasma.desktop-appletsrc:plugin=org.kde.plasma.showdesktop ``` My system is currently configured for two activities. If I search for "activity" there are four hits in ~/.config/plasma-org.kde.plasma.desktop-appletsrc. What do they mean? ``` [Containments][1] ItemGeometriesHorizontal= activityId=cb054e74-0743-40ef-a67e-796691eb4c30 formfactor=0 immutability=1 lastScreen=0 location=0 plugin=org.kde.plasma.folder wallpaperplugin=org.kde.image [Containments][19] ItemGeometriesHorizontal= activityId=74ea37e7-0d78-4216-9788-e9b9ededb800 formfactor=0 immutability=1 lastScreen=0 location=0 plugin=org.kde.plasma.folder wallpaperplugin=org.kde.image [Containments][2] activityId= formfactor=2 immutability=1 lastScreen=0 location=4 plugin=org.kde.panel wallpaperplugin=org.kde.image [Containments][8] activityId= formfactor=2 immutability=1 lastScreen=0 location=4 plugin=org.kde.plasma.private.systemtray wallpaperplugin=org.kde.image ```
Here are some specific problems which prevent me from storing plasma config in my dotfiles repo on GitHub and share it between several machines: 1) While configuration is in text format, it is not human-readable or human editable. For example, here's the start of my `~/.config/kglobalshortcuts`: ``` [ActivityManager] _k_friendly_name=Activity Manager switch-to-activity-91f1e606-4d43-4e12-85a2-7224a17f3330=none,none,Switch to activity "Default" [KDE Keyboard Layout Switcher] Switch keyboard layout to English (US)=none,none,Switch keyboard layout to English (US) Switch keyboard layout to English (Workman)=none,none,Switch keyboard layout to English (Workman) Switch keyboard layout to Russian=none,none,Switch keyboard layout to Russian Switch keyboard layout to us(workman)=none,none,Switch keyboard layout to us(workman) Switch to Next Keyboard Layout=none,Ctrl+Alt+K,Switch to Next Keyboard Layout _k_friendly_name=Keyboard Layout Switcher [kaccess] Toggle Screen Reader On and Off=,Meta+Alt+S,Toggle Screen Reader On and Off _k_friendly_name=Accessibility ``` As a human, that switch-to-activity-UUID doesn't make sense to me, so I can't modify it. 2) Configuration includes irrelevant information, so it is impractical to store it in version control. `kglobalshorctucs` contains 269 lines, although I've configured only a handful of keys. 3) Configuration mixes actual user configuration and machine-specific state. For example, my `~/.config/dolphinrc` starts like this: ``` DisplayPort-1 Window-Maximized 2560x1440=true DisplayPort-1 XPosition 2560x1440=0 DisplayPort-1 YPosition 2560x1440=24 State=AAAA/wAAAAD9AAAAAwAAAAAAAABXAAAFPPwCAAAAAvsAAAAWAGYAbwBsAGQAZQByAHMARABvAGMAawAAAAAA/////wAAAAoBAAAD+wAAABQAcABsAGEAYwBlAHMARABvAGMAawEAAABMAAAFPAAAAF0BAAADAAAAAQAAAAAAAAAA/AIAAAAB+wAAABAAaQBuAGYAbwBEAG8AYwBrAAAAAAD/////AAAACgEAAAMAAAADAAAAAAAAAAD8AQAAAAH7AAAAGAB0AGUAcgBtAGkAbgBhAGwARABvAGMAawAAAAAA/////wAAAAoBAAADAAAJqAAABTwAAAAEAAAABAAAAAgAAAAI/AAAAAEAAAACAAAAAQAAABYAbQBhAGkAbgBUAG8AbwBsAEIAYQByAQAAAAD/////AAAAAAAAAAA= ``` The size of whatever in pixels is very clearly specific to my desktop machine, but I would like to share and synchronize the same config file between my desktop and my laptop. As a positive example of a configuration file which can be managed as text, consider my .xbindkeysrc: ``` λ bat -p ~/.xbindkeysrc "jumpapp -m kitty" F1 "jumpapp -m vivaldi" F2 "krunner" F3 "jumpapp -m code" F4 "jumpapp -mf telegram-desktop" F5 "jumpapp -m deadbeef" F6 "code --new-window ~/work/" F7 "jumpapp -m dolphin" Mod4 + e ``` Here, everything was typed by me, doesn't include opaque data like uuids or base64 encoded strings, and includes only the diff I've made to the default config.
Thanks for the input! There are some low-hanging fruits that would address some of the specific problems you are mentioning and better separation between volatile state and configuration is being worked on. However generally the configuration files are implementation details of the applications and not something we actively design for the use case of editing them manually. Doing so would be a huge amount of work that we wouldn't be able to put elsewhere, so I can't promise things will ever be like what you are describing
You already can. All configuration is stored in human-readable and -writable text files.
The title is somewhat unrelated to the actual issues raised though. The configurations being text don't have much to do with them being machine-dependant
I realized that there's one more specific thing. For keyboard shortcuts specifically, there's "Import Scheme/Export Scheme" gui workflow, which is _different_ from just sharing a config file. It'd be cool if we didn't need the "Import/Export" functionality at all, and instead just had a link to where the config file is.
(In reply to Nicolas Fella from comment #6) > The title is somewhat unrelated to the actual issues raised though. The > configurations being text don't have much to do with them being > machine-dependant You're completely right. I've edited the title accordingly.
Just came across this issue in my quest to be able to make my KDE Plasma environment completely reproducible. Surely, it's a huge undertaking, but I am glad to learn that KDE developers are working towards it. I did not realize what a joy it is to be able to reproduce an exact environment (be it desktop, development, or test) until I recently switched to NixOS. That's when the distinction between user preferences v/s application state became clear to me. Because of that, my views are slightly different on storing-preferences-is-an-implementation-detail. IMHO, preferences are an interface that the application exposes to the users. Using GUI is only one way to manipulate the preferences. Ability to store them in a simple (with emphasis on simple) text file so that one can store them in GitHub, or use something like Nix or Ansible to manage them is also important. Thank you for all the amazing work you do!
Not mentioned so far... https://discourse.nixos.org/t/how-to-configure-kde-properly-in-nix/21362