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)
> This definitely falls under the category of "over-broad requests for giant changes to everything", Indeed. :) The issue here is that there's no single magic bullet solution. Every app and also Plasma needs to be ported to save its state in its state file rather than its config file. This has been happening slowly, and some apps like Dolphin do it now, but in the end, every single app needs to be ported to do it. It can't be done automatically because someone needs to make the judgment about what counts as state and what counts as settings and handle them separately. If you'd like to help out with this effort, it could be a good place to get involved. It's not hard to do. Here are the two commits that did it for Dolphin, for example: - https://invent.kde.org/system/dolphin/-/commit/946b911a5d340d7672db9802579f658aeba738b0 - https://invent.kde.org/system/dolphin/-/commit/b497dc9cbd1236790b5267710f5fb8370253d005 Not too bad, right? It's basically a matter of replacing "KSharedConfig::openConfig()" function calls with "KSharedConfig::openStateConfig()" for data that should be considered semi-volatile state, not user settings. So maybe you can help by making similar changes for apps where you encounter this problem. If not, then it would be useful if you could submit a bug report for each individual app that exhibits this problem, and then add it to the "see also" list in Bug 397602. > A temporary fix that would make me happy is a command-line configuration interface that can comprehensively configure most applications We have this; check out `kreadconfig5` and kwriteconfig5`. *** This bug has been marked as a duplicate of bug 397602 ***
(In reply to Nate Graham from comment #1) > If you'd like to help out with this effort, it could be a good place to get > involved. It's not hard to do. Here are the two commits that did it for > Dolphin, for example: > - > https://invent.kde.org/system/dolphin/-/commit/ > 946b911a5d340d7672db9802579f658aeba738b0 > - > https://invent.kde.org/system/dolphin/-/commit/ > b497dc9cbd1236790b5267710f5fb8370253d005 > > Not too bad, right? It's basically a matter of replacing > "KSharedConfig::openConfig()" function calls with > "KSharedConfig::openStateConfig()" for data that should be considered > semi-volatile state, not user settings. So maybe you can help by making > similar changes for apps where you encounter this problem. > > If not, then it would be useful if you could submit a bug report for each > individual app that exhibits this problem, and then add it to the "see also" > list in Bug 397602. Thank you for collecting these commits. I am working on a repository similar to these: + https://github.com/ectorepo/tensorflow + https://github.com/ectorepo/ROCmSoftwarePlatform The placeholder is here, but I've been busy for awhile: + https://github.com/ectorepo/kde This will allow me to clone all of the projects on invent.kde.org, which should be finished soon. I should be able to extract the information I need from GraphQL that allows me to check the projects into a file tree based on their category/project or something. I usually use this approach to keep large codebases in sync where the codebases are intended for reference only. After running `repo init` and `repo sync`, then everything is up-to-date. The sync command can specify projects by "group" which functions like a tag. I don't know that I will have the time to work on anything. It just depends, perhaps in the next few months or so. > We have this; check out `kreadconfig5` and kwriteconfig5`. > > *** This bug has been marked as a duplicate of bug 397602 *** I will look into those. Thanks again.