Cleaning up config files

[Duncan]

Jerome Yuzyk posted on Sun, 13 Jan 2019 15:47:08 -0700 as excerpted:

> I have been maintaining my KDE configuration across several Fedora
> releases, since Fedora 18. My /home has always lived on a separate disk
> from /.
> 
> About 9 months ago my /dev/sda died and I replaced it and installed
> Fedora 28, with its KDE 5 configuration.
> 
> Over that time my /home/me KDE config files have been moved to different
> directories, distributed among these $HOME directories:
> 
>     .config   .kde    .local
> 
> Now it's winter, and time to do some system admin, and I'd like to clear
> out the cruft from past KDE incarnations on /home/me.
> 
> Before I grunt through the process of comparing .config/.kde/.local
> files, is there a list of what places KDE configs live with KDE5?

With gentoo being a rolling distro and my install being back in 2004, 
with some of the user settings from back then migrated from mandrake, 
I've actually been rolling some of my kde install from the kde2 and IIRC 
even some kde1 era circa the turn of the century, when I upgraded from MS!

So I've done cleanup a few times by now.

But the kde4 -> plasma5 on kde-frameworks5 migration is a pretty big one, 
because most of the settings are finally moving out of the old kde-
specific locations, normally under ~/.kde, to the newer xdg desktop 
specification locations, defaulting to ~/.config and ~/.local if the 
appropriate XDG_(CONFIG|DATA)_HOME vars aren't set (which you'd 
presumably know if you set them, as I do).

FWIW, unless you still have kde4 apps hanging around, pretty much the 
only thing likely to still be current-updated in ~/.kde is the old kde4-
version kdeglobals file (I believe ~/.kde/share/config/kdeglobals by 
default, tho I've long set the KDEHOME var so mine was different, the kde5 
version is elsewhere) that has continued to be maintained in plasma5, 
primarily for legacy/compatibility reasons.  At least, that's what I 
found recently here (tho note I don't have a full kde-apps/plasma 
install, so it's possible I missed some, backup the dir first before 
deleting, just to be safe), with no kde4 apps at all still around, when 
after backing it up, I decided to try clearing out ~/.kde, just to see 
what files, if any, got recreated.

And since I don't have any kde4 apps left to read it and I wanted to be 
rid of the old $KDEHOME (~/.kde by default) location, I simply set/
exported KDEHOME pointing at my user's $TMPDIR location, which happens to 
be on tmpfs, so it's actually in RAM and is thus empty and recreated at 
each boot once I run startx/startkde from my usual CLI login.[1]  Then I 
could delete the old $KDEHOME dir and not have it recreated just to put 
the old kde4-version kdeglobals file in.

Meanwhile, since that old kde4-version kdeglobals file is now in tmpfs 
and recreated once each boot, I can be it's all written fresh and none of 
the settings are stale, from what /used/ to be installed.  It seems it's 
mostly color settings, with a few font and icon settings, etc, as well, 
still setup by plasma5's color/font/icon/etc theming engine in ordered to 
keep compatibility with the kde4 stuff, since they actually learned from 
the history of the kde3->kde4 upgrade fiasco and kept supporting the core 
kdelibs4 stuff for quite some time, allowing devs and distros/users to 
upgrade individual apps to their frameworks5 versions one-at-a-time as 
the individual v5 versions matured enough to be usable. =:^)  And to keep 
it all working smoothly, they're still exporting kde4 versions of the 
frameworks/plasma5 settings via kdeglobals, for any kde4 apps that the 
user may still have running. =:^)

But once you are sure you don't have any kde4 apps left (here I have no 
kdelibs4 and no qt4 installed, so I'm sure -- and they couldn't run if 
they /were/ still somehow installed!), you don't need that, and if you 
wish, you can do as I did and point the legacy $KDEHOME var to some place 
other than its default ~/.kde, allowing you to delete that old dir 
entirely.

Meanwhile, as mentioned, the new kde-frameworks5/plasma5 locations are XDG 
compliant.  Again, I actually set my vars so I don't use the defaults, 
but here's the info on them.  In brief, ~/.config is the $XDG_CONFIG_HOME 
default and normally stores configuration settings, while ~/.local/share 
is the $XDG_DATA_HOME default and normally stores non-config data.

To give you some idea of the practical config/data separation, picking 
one example I happen to know about, plasma's comic-strip plasmoid/widget:

Most of the comic-strip plasmoid settings, as with most plasmoid 
settings, are stored in $XDG_CONFIG_HOME/plasma-org.kde.plasma.desktop-
appletsrc (thus ~/.config/plasma-org.kde.plasma.desktop-appletsrc by 
default, if you customize your plasma desktop as much as I do, having a 
backup of that file and knowing what file to replace with that backup if 
necessary can save you a *LOT* of trouble recustomizing if it gets 
corrupted!)

But the cache of downloaded comics themselves are data, and thus can be 
found in the $XDG_DATA_HOME/plasma_engine_comic/ subdir, ~/.local/share/
plasma_engine_comic/ by default, if $XDG_DATA_HOME isn't set.

However, the config/data split isn't absolute.  To avoid having to manage 
another directory location or store all the strip configuration details 
in the global desktop-appletsrc file, the comic-strip plasmoid stores 
some config files, the individual comic *.conf files, for instance, in 
the data dir along with the comics, as well.

Or for most but not all kde-frameworks-based apps including core plasma 
apps, a general rule of thumb that does have some exceptions is that if 
the config data in question can neatly fit into a single file, look first 
for it in the config location (~/.config), while if there's likely to be 
too much for a single file and/or if there's non-config data such as 
images, look in the data location (~/.local/share/<app-name>).  (This is 
an update to the similar kde3/4 rule of thumb that had individual files 
in ~/.kde/config/ by default, while larger/multiple files per app were 
normally found in an app-titled subdir of ~/.kde/share.)

Meanwhile, to put it in terms of the KDE sysadmin guide, describing both 
the user and system locations, found here:

https://userbase.kde.org/KDE_System_Administration

The KDE Filesystem Hierarchy page deals with legacy kde4 and earlier, 
while the XDG Hierarchy page deals with the new locations.  Meanwhile, 
the Environmental Variables page covers the variables for both, with 
section 4, File System, dealing with the legacy KDEDIRS/KDEHOME, etc, 
locations, while section 11, freedestkop.org Compliance, covers the newer 
XDG_* vars that frameworks5 stuff uses.

---
[1]  No *DM graphical login here, I use a CLI login and if I want to run 
X/kde, I run a local script that runs startx, which in turn launches 
startkde for my X session).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman