There’s a proposal at the linked blog post for how to clean up the config directory.
The post goes into detail which changes would be required in KDE software using Qt.
After reading, I just have one question (the blog does not seem to have a comment section): how does this handle transitioning from the old location to the new location? Imagine having a katerc config file under ~/.config and one under ~/.config/kate (which is the suggestion from the post) - should those be merged once and then the old one gets deleted?
I answered something similar elsewhere:
If you mean migrating the files yourself, it’s just a matter of copying the file from the old place ~/.config/yourconfigrc to ~/.config/yourapp/yourconfigrc.
If you mean you want the application to manage the migration itself, that’s an implementation detail I hadn’t thought about yet, but which I assume wouldn’t be difficult to do with KConfig.
You can see this bit of code from Konsole showing how to migrate from old entries to new entries in the same config file for example: >https://invent.kde.org/utilities/konsole/-/blob/master/src/main.cpp#L99
The implementation could probably be something similar, with two KConfig/KSharedConfigPtr instances I assume 👀 so:
- if oldConfig exists, create an object for it
- read all oldConfig entries
- if it differs from newConfig, store which ones differ
- write all different oldConfig entries in newConfig object
- sync()
Something like that.
Just for clarification: this would be a one-time process per application, right? I’m sure this will work for 99% of users, but there’ll always be the one (or a couple of users) that synchronizes their .config directory, then doesn’t update all machines at the same time and all hell breaks loose - a.k.a https://xkcd.com/1172/ :-) But I’d say that’s probably not worth losing the advantages of a cleaner .config-directory, so this might be one of those “tough-luck” situations… 🤷
I think so. I mean, the migration code would still be there afterwards, maybe removed after several versions later.
If the user syncs machines with different application versions I’m not sure there’s anything that can be done at the code level though. 👀
i agree with all of this, and in fact would go a step further to say: nicer names in general. what in the nine is
plasma-org.kde.plasma.desktop-appletsrc‽ why not justplasma-appletsrc?i think the real problem is the manpower to do it all though
Would this mean a copy and a paste of the config folder would bring up a new KDE system to my personalizing without going through konsave juggling?
I think that’s my biggest complaint that I don’t know how to import my desktop config (window decorations, panel layout, desktops, activities, fonts, application themes) into a new install easily or the “proper” way
this is a seperate issue, and no, it wouldn’t fix the issue, maybe improve it a little though. as stated in the article, not everything would be in ~/.config/kde, and IME there are files scattered over ~/.local/share that you might also consider config you want to export.
Personally, I’ve tracked down 80-90% of the settings I care about and put them in git, but it was tedious, and some things can’t really be shared across machines, while some other things need to be cleared of machine specific information to work as a new “default base config”
I’m not sure (not the author) and I think syncing config is a lot more difficult than it would seem at first glance. Eg Panel Layout: Imagine syncing between a multi-monitor-setup (work PC) and a single-monitor-setup (Laptop) - how’s that supposed to work? The panel might be on the second screen on the PC, but once synchronized to the Laptop, that would mean either
- missing panel (off screen)
- double panel (stacked on top of each other)
- hidden second panel (one below the other)
- …
Syncing .config would (at first glance) work best for device independent settings (e.g.: Indentation in Kate with Tabs vs. Spaces) - but even “fonts” in Kate might already not be a good idea, as a font might not be installed in both systems (and it might get worse with font-sizes, scale-factors…)
i haven’t looked too deeply into it, but a lot of kde config files already have some sort of update and version data. transitioning to new locations shouldn’t be TOO difficult. I think everyone can agree it should be done. I imagine that naming and specific locations could turn into bikeshedding though.
It’s been tempting for me to use some LD_PRELOAD magic to clean things up. I’m the kind of person that keeps my home directory read-only and uses custom environment variables for particularly egregious applications.
@MartinR the Maven convention for packaging is a group identifer/package is the inverse domain order.
Taking
plasma-org.kde.desktop-appletsrcyou would create a group identifer of:org.plasma.kde.desktopWith the artefact identifier being:appletsrc.The folder structure would then look like:
.config \-\>org \-\>-\>plasma \-\>-\>-\>kde \-\>-\>-\>-\>desktop \-\>-\>-\>-\>-\>appletsrcIts simple
The proposal isn’t mine, I just read and shared it :-) The blog post has a paragraph or two about multpile subfolders, as I read it, the specification is not clear on whether thats supported? But actually: at first glance I think this would be better to have, because it would possibly make synchronizing to a new PC/Laptop even easier. However, this only works if any machine-specific settings (e.g. “offset /size of window”) are not stored in config, as that might break if you sync config between a multi-monitor setup and a single-monitor setup. This requires a lot of thought…
That feels way too nested to be useful IMHO. It’s great for packaging dev tools, but not really for handling config directories for user space apps. I just want
~/.config/KDE/<app>I always considered plasma to be a part/sub project of kde, therefore org.kde.plasma would seem correct-er.
