Bug 468997

SUMMARY

I would like to have some deterministic way to comprehensively reproduce a KDE Desktop system. Such a system would also lend itself to configuration stored in dotfiles. I realize how broadly this affects KDE/QT, but it would: 

- allow sharing configuration snippets
- reduce trivial bugs and facilitate CI/CD to prevent regression
- magnify KDE developer productivity
- broaden KDE Desktop feature utilization
- encourage ROI for KDE customization

You can find my dotfiles here: https://github.com/dcunited001/ellipsis

This definitely falls under the category of "over-broad requests for giant changes to everything", however it is a major impediment to the growth of KDE:

- you can't easily share configs
- you can't easily edit the plasma docs with text files (unless it's javascript, which works)
- you can't easily restore a desktops state
- you can't easily store KDE config files in a dotfiles repo
- you can't easily construct CI/CD that tests known configurations for bugs/regressions
- you can't easily prevent corrupted config files from forcing the user to abandon customizations and start from scratch using the GUI.

I understand that this is somewhat possible by producing KDE desktop widgets/configs with javascript or some other languages.

https://gitlab.com/garuda-linux/themes-and-settings/settings/garuda-dr460nized/-/blob/master/usr/share/plasma/look-and-feel/Dr460nized/contents/layouts/org.kde.plasma.desktop-layout.js

And I could easily be convinced that this would be sufficient -- if so, please help me understand why such methods are not more broadly documented so they could be available outside of the KDE developer community. You have a fantastic WM -- with very good compositing/features and advanced support for wayland! However, it has only marginally been worthwhile to invest time in configuring the desktop to feel exactly the way I want (customization is very important to me). There are some other problems I mention at the end

STEPS TO REPRODUCE
1. Change any configuration setting
2. Run `git diff` on your dotfiles or $XDG_CONFIG_HOME
3. State (e.g. recent files, base64 encoded data, etc) shows up in KDE config files

OBSERVED RESULT

- Making small changes results in changes to base64 encoded hashes in config files.
- Lines from the terse KDE/QT config format need to be staged by hunk.
- When on my KDE system, I have to constantly `git stash` and `git stash pop` around any `git pull`

EXPECTED RESULT

State should /NOT/ be in `$XDG_CONFIG_HOME`. According to the XDG Base Directory Specification this should be in:

- cache: XDG_CACHE_HOME
- state: XDG_STATE_HOME
- runtime: XDG_RUNTIME_DIR

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

A temporary fix that would make me happy is a command-line configuration interface that can comprehensively configure most applications -- like the old Mac OS X `defaults write` CLI: https://github.com/dcunited001/dc.files.osx/blob/master/osx.sh

I understand that such a CLI this exists for theming, but using it feels a bit ad-hoc since it's not comprehensive. I also understand how comprehensive and sweeping such changes would be. However, it is incredibly frustrating to see KDE be so good, yet so impossibly far away from having this.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Problems with non-deterministic state in config files:

- It's too easy for Latte Dock configuration to drift or to include invisible/buggy elements, resulting in the need to completely reset the configuration and start from scratch. No doubt this has created bad experiences and a high volume of unnecessary bugs in bugs.kde.org.

- While syncing files to a backup or using an image-based backup of a home directory is probably the preferred means of restoring KDE desktop state, the unmergeability of the TOML configs (wierd usage of ID's, etc) means that for small changes or when distro-hopping, you're better off just throwing everything out. This means 20+ hours of work for me to switch between Garuda Arch or Fedora Silverblue (or uBlue) 

- While the Plasma dock is the new norm, I can't easily copy/past various Performance definitions or the config thereof. I've spent a lot of time doing this, but I can't easily save or replicate my work -- this means I wouldn't actually use features like custom docks that I hide or show with a keybinding. While the plasma dock widgets should support changing the sizes, you can only easily do so by creating custom widgets by extending from them. If this is the best way to reliably recreate or duplicate widgets on a dock, then it's likely worth it.

- Ensuring some security-related changes have taken place is difficult: enforcing a max clipboard history on Klipper is essential, IMO. Such changes are easily forgotten on a new installation.

Thanks for listening to my opinions. This is seriously the biggest gripe I have with KDE, which is otherwise pretty spectacular (albeit a bit imitative of Windows/OSX)