https://bugs.kde.org/show_bug.cgi?id=468997
Bug ID: 468997
Summary: Feature Request: deterministic KDE/QT config format
Classification: Applications
Product: systemsettings
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: dconner....@gmail.com
Target Milestone: ---
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)
--
You are receiving this mail because:
You are watching all bug changes.
