Bug 422529 - Put config files inside a kde subdirectory in ~/.config, ~/.local/share, and ~/.cache
Summary: Put config files inside a kde subdirectory in ~/.config, ~/.local/share, and ...
Status: CONFIRMED
Alias: None
Product: frameworks-kconfig
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Matthew Dawson
URL:
Keywords: geezer-jobs
: 422920 430425 460400 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-06-06 11:18 UTC by Artem S. Tashkinov
Modified: 2023-11-12 15:53 UTC (History)
35 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Artem S. Tashkinov 2020-06-06 11:18:55 UTC
I would love KDE developers to reconsider their decision to kill ~/.kde for storing KDE apps configuration, caches, etc.

I'm not talking about reviving ~/.kde{,5} per se but I wanna offer an alternative:

Let's store the files for KDE based applications in

~/.config/kde/
~/.local/share/kde/
~/.cache/kde/

Why do I think this is necessary? Almost two years ago I tried running KDE and it created a huge mess under ~/.config/ :

-rw-------.  1 user user  1428 Nov 21  2018 akregatorrc
-rw-------.  1 user user   749 Nov 21  2018 baloofileinformationrc
-rw-------.  1 user user   818 Nov 20  2018 baloofilerc
-rw-------.  1 user user    34 Nov 20  2018 device_automounter_kcmrc
-rw-------.  1 user user  1092 Nov 21  2018 dolphinrc
-rw-------.  1 user user    58 Nov 20  2018 emaildefaults
-rw-------.  1 user user    24 Nov 20  2018 fedora-plasma-cacherc
-rw-------.  1 user user 41724 Nov 21  2018 fsviewrc
-rw-------.  1 user user   807 Nov 20  2018 jukrc
-rw-------.  1 user user   696 Nov 20  2018 kaccessrc
-rw-------.  1 user user   119 Nov 20  2018 kactivitymanagerdrc
-rw-------.  1 user user  1939 Nov 21  2018 kactivitymanagerd-statsrc
-rw-------.  1 user user    56 Nov 20  2018 kateschemarc
-rw-------.  1 user user   279 Nov 21  2018 kcalcrc
-rw-------.  1 user user   227 Nov 21  2018 kcmcssrc
-rw-------.  1 user user    27 Nov 20  2018 kcmdisplayrc
-rw-------.  1 user user    51 Nov 20  2018 kcmfonts
-rw-------.  1 user user    43 Nov 20  2018 kcminputrc
-rw-------.  1 user user    94 Nov 21  2018 kcmshell5rc
-rw-------.  1 user user  1057 Dec 20  2018 kconf_updaterc
-rw-------.  1 user user   144 Nov 21  2018 kcookiejarrc
-rw-------.  1 user user    43 Dec 20  2018 kded5rc
-rw-------.  1 user user  1707 Nov 20  2018 kded_device_automounterrc
-rw-rw-r--.  1 user user  3515 Nov 21  2018 kdeglobals
-rw-------.  1 user user    72 Nov 20  2018 kfontinstuirc
-rw-------.  1 user user 13152 Dec 20  2018 kglobalshortcutsrc
-rw-------.  1 user user 30769 Dec 20  2018 khotkeysrc
-rw-------.  1 user user    83 Nov 21  2018 kio_httprc
-rw-------.  1 user user   127 Nov 21  2018 kiorc
-rw-------.  1 user user    41 Nov 20  2018 klipperrc
-rw-------.  1 user user    69 Nov 20  2018 kmail2rc
-rw-------.  1 user user    74 Nov 20  2018 kmixrc
-rw-------.  1 user user   738 Dec 20  2018 knemorc
-rw-------.  1 user user    35 Nov 20  2018 knfsshare
-rw-------.  1 user user    39 Nov 20  2018 knotifyrc
-rw-------.  1 user user    33 Dec 20  2018 konq_history
-rw-------.  1 user user  1774 Dec 20  2018 konquerorrc
-rw-------.  1 user user  1536 Nov 21  2018 konsolerc
-rw-------.  1 user user   154 Dec 20  2018 krunnerrc
-rw-------.  1 user user    54 Nov 20  2018 kscreenlockerrc
-rw-------.  1 user user   179 Nov 21  2018 kservicemenurc
-rw-------.  1 user user    33 Nov 20  2018 ksplashrc
-rw-------.  1 user user   110 Nov 20  2018 ktimezonedrc
-rw-------.  1 user user   168 Nov 20  2018 kuriikwsfilterrc
-rw-------.  1 user user  1607 Dec 20  2018 kwinrc
-rw-------.  1 user user    18 Dec 20  2018 kwinrulesrc
-rw-------.  1 user user    87 Nov 20  2018 phishingurlrc
-rw-rw-r--.  1 user user    27 Nov 20  2018 plasma-localerc
-rw-------.  1 user user 11239 Dec 20  2018 plasma-org.kde.plasma.desktop-appletsrc
-rw-------.  1 user user    20 Nov 21  2018 plasmarc
-rw-------.  1 user user   709 Dec 20  2018 plasmashellrc
-rw-------.  1 user user    44 Nov 20  2018 powerdevilrc
-rw-------.  1 user user   698 Nov 20  2018 powermanagementprofilesrc
-rw-rw-r--.  1 user user   441 Dec 20  2018 startupconfig
-rw-rw-r--.  1 user user  1193 Dec 20  2018 startupconfigfiles
-rw-rw-r--.  1 user user   217 Dec 20  2018 startupconfigkeys
-rw-------.  1 user user  1395 Nov 21  2018 systemmonitorrc
-rw-------.  1 user user   255 Nov 21  2018 systemsettingsrc
-rw-------.  1 user user   633 Nov 20  2018 user-dirs.dirs
-rw-rw-r--.  1 user user     5 Nov 20  2018 user-dirs.locale

to be honest I'm not a huge fan of it.

For instance XFCE4 has all its files stored neatly in ~/.config/xfce4 and it's quite easy to work with them (keep track of, save, restore, grep, etc).

Right now KDE settings are mingled with all other applications and it doesn't look pretty and makes things complicated.
Comment 1 Nate Graham 2020-06-11 03:40:58 UTC
This seems reasonable to me.

Probably a KF6 topic though.
Comment 2 Nate Graham 2020-06-13 16:48:49 UTC
*** Bug 422920 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Feck 2020-06-14 01:31:37 UTC
Looking at the directory listing at comment 0, I don't spot any non-KDE configuration file, so moving them all to a /kde subfolder won't gain you anything. Did I understand anything wrong?
Comment 4 Artem S. Tashkinov 2020-06-15 19:00:37 UTC
(In reply to Christoph Feck from comment #3)
> Looking at the directory listing at comment 0, I don't spot any non-KDE
> configuration file, so moving them all to a /kde subfolder won't gain you
> anything. Did I understand anything wrong?

As far as I can see almost all the files in the original listing belong to KDE or KDE components. They weren't there before I ran KDE5 for the first time.

BTW some rare components write to ~/.config/kde.org e.g. libphonon.conf but otherwise this directory is empty.
Comment 5 Nate Graham 2020-12-16 21:48:31 UTC
*** Bug 430425 has been marked as a duplicate of this bug. ***
Comment 6 Artem S. Tashkinov 2022-10-09 14:47:09 UTC
(In reply to Nate Graham from comment #1)
> This seems reasonable to me.
> 
> Probably a KF6 topic though.

The bug/feature request has been laying dormant for two years and since KDE 6 is on the horizon, I want to hope the request will not be forgotten.
Comment 7 Nate Graham 2022-10-14 20:23:17 UTC
*** Bug 460400 has been marked as a duplicate of this bug. ***
Comment 8 Volker Krause 2023-01-24 16:37:05 UTC
I don't think KConfig is the right place for this. The library one happens to use for accessing a config file shouldn't just add its own vendor prefix. I can see why we might want some grouping of the config files, but that should be per product or product group (say Akonadi-based PIM or Plasma), not per config library vendor.

Should someone want to implement this, this also needs considering migrating existing files and we need to account for application code that for whatever reason searches for config file locations manually. So this is much more than just adding an extra prefix in one place. Whether that effort/risk is worth the gain is another question.
Comment 9 Artem S. Tashkinov 2023-01-25 00:14:55 UTC
(In reply to Volker Krause from comment #8)
> I don't think KConfig is the right place for this. The library one happens
> to use for accessing a config file shouldn't just add its own vendor prefix.
> I can see why we might want some grouping of the config files, but that
> should be per product or product group (say Akonadi-based PIM or Plasma),
> not per config library vendor.
> 
> Should someone want to implement this, this also needs considering migrating
> existing files and we need to account for application code that for whatever
> reason searches for config file locations manually. So this is much more
> than just adding an extra prefix in one place. Whether that effort/risk is
> worth the gain is another question.

Lots of people do not want to see all their KDE configuration files under `~/.config`.

XFCE for instance has its own prefix `~/.config/xfce4` which makes it easy to reset XFCE settings without touching anything else.

KDE makes it wholly impossible and not only that, ~/.config with KDE5 installed looks like a complete mess.

I'm pretty sure `~/.config` is hardcoded somewhere and changing it to e.g. `~/.config/kde6` must be relatively easy. I've no idea what the right component is, I'm not a KDE developer, I don't have to know that. I want that to be fixed, and not only me, but other people as well.

I also don't quite understand the whole "migration" issue. I believe nothing should be migrated automatically. People who upgrade from KDE5 to KDE6 will have a brand new clean environment unless they manually move the necessary files. It's actually a good thing. Less junk, fewer issues related to older config files.

I also don't understand why you paint it as something complicated which could have its pitfalls. KDE3 had it's own `~/.kde3` path which was changed to `~/.config`. I don't remember any significant issues or arguments over that. Someone just did it.
Comment 10 Volker Krause 2023-01-25 16:33:37 UTC
(In reply to Artem S. Tashkinov from comment #9)
> I also don't quite understand the whole "migration" issue. I believe nothing
> should be migrated automatically. People who upgrade from KDE5 to KDE6 will
> have a brand new clean environment unless they manually move the necessary
> files. It's actually a good thing. Less junk, fewer issues related to older
> config files.
Upgrading to a newer version must not lose configuration settings, and we always tried to avoid that. The fact that this didn't always work reliably is exactly the problem.

> I also don't understand why you paint it as something complicated which
> could have its pitfalls. KDE3 had it's own `~/.kde3` path which was changed
> to `~/.config`. I don't remember any significant issues or arguments over
> that. Someone just did it.
You might not remember it, but that did cause various config loss issue and involved way more than a single line code change.
Comment 11 Artem S. Tashkinov 2023-01-25 20:38:30 UTC
(In reply to Volker Krause from comment #10)

This is all quite sad to hear.

Not meaning anything personal, but it all sounds like "We didn't put too much thought into storing all the settings in ~/.config and now we don't want to fix the mess because some people will be mad".

Weirdly, I vividly remember that throughout KDE3 releases there was some KDE daemon which updated configuration files when necessary and kept track of them. Looks like this has become an impossible task despite many more KDE developers nowadays and simple tools like grep for fixing this issue in code.

Here's something which could solve the issue:

```C++
bool fileExists(QString path) {
    QFileInfo check_file(path);
    // check if file exists and if yes: Is it really a file and no directory?
    if (check_file.exists() && check_file.isFile()) {
        return true;
    } else {
        return false;
    }
}

QDir dir;

if (fileExists("$HOME/.config/$appname.conf" && !fileExists("$HOME/.config/kde6/$appname.conf"))
    dir.rename(QLatin1String("$HOME/.config/appname.conf"), QLatin1String("$HOME/.config/kde6/appname.conf"));
```

If you're opposing to fixing this issue, it's worth closing as WONTFIX. As for me I will continue to use XFCE4. Yes, this bug is probably the biggest issue I refuse to use KDE (and I ran KDE3.5.10 for almost a decade after you stopped supporting it). I like my $HOME neatly organized and considering this bug duplicates I'm not alone in my aspirations.
Comment 12 Volker Krause 2023-01-25 21:32:47 UTC
(In reply to Artem S. Tashkinov from comment #11)
> If you're opposing to fixing this issue, it's worth closing as WONTFIX. As
> for me I will continue to use XFCE4. Yes, this bug is probably the biggest
> issue I refuse to use KDE (and I ran KDE3.5.10 for almost a decade after you
> stopped supporting it). I like my $HOME neatly organized and considering
> this bug duplicates I'm not alone in my aspirations.

Please see my first reply: I'm not opposing changing this, I am opposing just adding a vendor prefix in the config file library (which is the component this is currently assigned to), as that is used by many different products.
Comment 13 Artem S. Tashkinov 2023-02-28 07:22:20 UTC
(In reply to Volker Krause from comment #12)
> 
> Please see my first reply: I'm not opposing changing this, I am opposing
> just adding a vendor prefix in the config file library (which is the
> component this is currently assigned to), as that is used by many different
> products.

I've no idea what the proper component is and how this needs to be handled.

I just don't want this bug report/feature request to be forgotten/abandoned because as soon as you release the first beta no one will want to change anything and the issue will be delegated to KDE7 to be released many years in the future.
Comment 14 Matthias Mueller 2023-02-28 07:58:13 UTC
Just wanted to add that this indeed is something that kind of bothered me with KDE forever. Nothing dealbreaking for me, but it would be nice to have more order in the configs for easier backup/restore.

I don't even think it has to be done forcefully - just transition every piece of software when it's developer has time. So maybe more a change of the guidelines than a real change in the framework?
Comment 15 feature 2023-02-28 15:08:51 UTC
(In reply to Volker Krause from comment #8)
> I don't think KConfig is the right place for this. The library one happens
> to use for accessing a config file shouldn't just add its own vendor prefix.
> I can see why we might want some grouping of the config files, but that
> should be per product or product group (say Akonadi-based PIM or Plasma),
> not per config library vendor.
> 
> Should someone want to implement this, this also needs considering migrating
> existing files and we need to account for application code that for whatever
> reason searches for config file locations manually. So this is much more
> than just adding an extra prefix in one place. Whether that effort/risk is
> worth the gain is another question.

What product groups are you suggesting?
I think having all KDE related configs in KDE is enough, and than it'd make sense to have that prefix hard coded in kconfig.

But If you want to be more flexible, kconfig can add a prefix argument to the load and save functions whose default is "kde", and have the products specify their custom prefixes if they want to relate themselves to a certain product family. 

And for a smooth transition, the load function can be wrapped with a try catch clause that would try to load with the prefix, and if it fails look for the config outside the prefix and move it inside the prefix, living a symbolic link outside.
Comment 16 feature 2023-02-28 15:11:58 UTC
When I said wrap the load function in try catch, I meant put the try catch inside the load function, not in the calling site. re-reading my comment made me realize I've worded it badly.
Comment 17 Joe 2023-02-28 22:05:40 UTC
Also chiming in that I never thought dumping everything in ~/.config was ideal and would love more organization, too, of config files. I had thought maybe a ~/.config/plasma for all core plasma/Plasma Desktop configs and a ~/.config/.kde-apps as default for any app configs - basically follow the current release bundling process and nomenclature.
Comment 18 alexmateescu 2023-02-28 22:53:49 UTC
(In reply to Joe from comment #17)
> Also chiming in that I never thought dumping everything in ~/.config was
> ideal and would love more organization, too, of config files. I had thought
> maybe a ~/.config/plasma for all core plasma/Plasma Desktop configs and a
> ~/.config/.kde-apps as default for any app configs - basically follow the
> current release bundling process and nomenclature.

I believe having more than one folder under .config defeats the purpose. The purpose being having the ability to backup/restore/delete KDE/Plasma config by changing just one folder. This is even beneficial for developers, because if users have an easy way to remove all settings, they can test cleanly a system that may have otherwise been migrated for years.
Comment 19 Artem S. Tashkinov 2023-03-01 07:04:01 UTC
(In reply to feature from comment #15)
> 
> And for a smooth transition, the load function can be wrapped with a try
> catch clause that would try to load with the prefix, and if it fails look
> for the config outside the prefix and move it inside the prefix, living a
> symbolic link outside.

If you move the config file inside the prefix, there's no need for a symlink. No symlinks please, it will only confuse people.
Comment 20 feature 2023-03-01 11:28:48 UTC
(In reply to Artem S. Tashkinov from comment #19)
> (In reply to feature from comment #15)
> > 
> > And for a smooth transition, the load function can be wrapped with a try
> > catch clause that would try to load with the prefix, and if it fails look
> > for the config outside the prefix and move it inside the prefix, living a
> > symbolic link outside.
> 
> If you move the config file inside the prefix, there's no need for a
> symlink. No symlinks please, it will only confuse people.

I've suggested using symlinks, for the cases in which external programs (not using kconfig) are looking for these config files in a hardcoded way... To make sure nothing breaks. these symlinks would only appear for people who migrate from a previous version, and it's very easy to clean up. Conversely, they are also quite easy to create if needed, and most people would probably not use any such external program... So I don't feel strongly about it either way. 

I was just addressing the concern that things might break if the config paths are changed, and I think my original suggestion is addressing any corner case that may arise.
Comment 21 feature 2023-03-01 11:36:26 UTC
(In reply to alexmateescu from comment #18)
> (In reply to Joe from comment #17)
> > Also chiming in that I never thought dumping everything in ~/.config was
> > ideal and would love more organization, too, of config files. I had thought
> > maybe a ~/.config/plasma for all core plasma/Plasma Desktop configs and a
> > ~/.config/.kde-apps as default for any app configs - basically follow the
> > current release bundling process and nomenclature.
> 
> I believe having more than one folder under .config defeats the purpose. The
> purpose being having the ability to backup/restore/delete KDE/Plasma config
> by changing just one folder. This is even beneficial for developers, because
> if users have an easy way to remove all settings, they can test cleanly a
> system that may have otherwise been migrated for years.

Aren't Plasma and kde-apps independent? They even have their own independent release schedule. I think separating kde-apps and plasma is a good idea. it'd only make a "complete" kde backup\restore require a single additional directory, while making it easier to backup\restore plasma independently.
Comment 22 Joe 2023-03-01 15:28:00 UTC
(In reply to feature from comment #21)
> (In reply to alexmateescu from comment #18)
> > (In reply to Joe from comment #17)
> > > Also chiming in that I never thought dumping everything in ~/.config was
> > > ideal and would love more organization, too, of config files. I had thought
> > > maybe a ~/.config/plasma for all core plasma/Plasma Desktop configs and a
> > > ~/.config/.kde-apps as default for any app configs - basically follow the
> > > current release bundling process and nomenclature.
> > 
> > I believe having more than one folder under .config defeats the purpose. The
> > purpose being having the ability to backup/restore/delete KDE/Plasma config
> > by changing just one folder. This is even beneficial for developers, because
> > if users have an easy way to remove all settings, they can test cleanly a
> > system that may have otherwise been migrated for years.
> 
> Aren't Plasma and kde-apps independent? They even have their own independent
> release schedule. I think separating kde-apps and plasma is a good idea.
> it'd only make a "complete" kde backup\restore require a single additional
> directory, while making it easier to backup\restore plasma independently.

Yeah exactly my fault. The plasma folder has all of the core plasma configs, and the app one would just be the misc dumping ground for any kde app (so anything from that release group, or even kde apps that are outside of the bigger package group release). In theory then if I wanted to reset KDE/Plasma I just nuke the plasma directory and all of my app settings stay.
Comment 23 feature 2023-03-02 10:44:28 UTC
Going over the code, my suggestion is making an overload for KConfig constructor, which takes an enum class ConfigAssociation { kde-app, plasma } as a fourth argument, in addition to file, mode and type (but present before type since it won't have a default value).

move the code in the current constructor to a private function, and call it from both the old constructor and the new suggested constructor, while also adding [[deprecated( "This constructor is deprecated, please specify association" )]] to the old constructor. 

The new constructor would check whether file exists, if so it'd move it to the appropriate prefix depending on the ConfigAssociation, prepend that prefix to file, and call the private constructor mentioned above.

This would make sure code for applications doesn't break, and once it's been adopted, the configuration is seamlessly moved to the new location. 

It's a very small change in code... Shall I make a PR?
Comment 24 Nate Graham 2023-03-02 14:21:42 UTC
Hey, that sounds like an eminently sane plan to me. I say go for it!
Comment 25 feature 2023-03-06 11:52:51 UTC
I've refactored most of the code. I now run into lots of deprecated warnings, naturally :)

This opens new questions:

1. How do we want to associate keyboard shortcut settings? Do we keep them outside, in kde-app, in plasma, or should we have a third category?

2. Will KConfigGui be exclusively used by kde applications, so we can write it to kde-app? or do we need to also deprecate its default constructor and require association?

3. Do you agree the KEmailSettings should be save to kde-app?

4. Where do we want kconf_updaterc to reside? (used by KonfUpdate (also, this name seems like a spelling error, it should probably have been KConfUpdate...)

There are also kreadconfig and kwriteconfig command line utilities which should probably get additional optional flag for association, and default to no association.

This had become much more pervasive a change than I had anticipated, but it's really close to a PR now.
Comment 26 tagwerk19 2023-03-06 13:08:42 UTC
(In reply to feature from comment #25)
> ... This had become much more pervasive a change than I had anticipated ...
It might be worthwhile posting a "heads up" on the Nixos forums.

There have been simmering discussions about what's needed to define a KDE setup for Nixos/Nix/Home Manager (as "Declarative KDE" rather than scripting the setup).

The problem statement or maybe a  "cri de couer":
    https://discourse.nixos.org/t/how-to-configure-kde-properly-in-nix/21362
and a tracking issue:
    https://github.com/nix-community/home-manager/issues/607
Comment 27 feature 2023-03-06 14:24:51 UTC
@tagwerk19, I'll look into these links.

Meanwhile, I've created a PR here: https://invent.kde.org/frameworks/kconfig/-/merge_requests/188
If anyone is willing to review, I'd appreciate it.
Comment 28 Artem S. Tashkinov 2023-08-13 15:06:03 UTC
What's the status of this feature request now that KDE6 is nearing its final release?

I don't think it's gonna be a good idea to fix/tackle it past the first final release.
Comment 29 sourcemaker 2023-08-21 00:05:05 UTC
The configuration files are just hell. 
Today I reinstalled Akonadi, and it's super tedious to gather everything together.
Apart from that, there are always leftovers from programs that are no longer used.

How about a separation according groups and products?

# Base directory for all KDE stuff
~/.config/kde/

# Program directory
~/.config/kde/$group/$product/

Examples:

# KDE accessibility applications
~/.config/kde/accessibility/

# KDE education applications
~/.config/kde/education/

# KDE games
~/.config/kde/games/

# KDE graphics applications
~/.config/kde/graphics/

# KDE multimedia applications
~/.config/kde/multimedia/

# KDE network applications
~/.config/kde/network/

# KDE office applications
~/.config/kde/office/

# KDE PIM applications
~/.config/kde/pim/

# KDE SDK applications
~/.config/kde/sdk/

# KDE system applications
~/.config/kde/system/

# KDE utilities applications
~/.config/kde/utilities/

# KDE Plasma
~/.config/kde/plasma/

For Akonadi und PIM it would be:

~/.config/kde/pim/akonadi/
~/.config/kde/pim/akregator/
~/.config/kde/pim/itinerary/
~/.config/kde/pim/kaddressbook/
~/.config/kde/pim/kalarm/
~/.config/kde/pim/kalendar/
~/.config/kde/pim/kleopatra/
~/.config/kde/pim/kmail/
~/.config/kde/pim/knotes/
~/.config/kde/pim/kontact/
~/.config/kde/pim/korganizer/
~/.config/kde/pim/zanshin/

Old programs that are no longer in use should be removed automatically.
Comment 30 Martino Fontana 2023-08-22 11:17:03 UTC
Adding to this, there's also the `KDEHOME` directory, which defaults to `~/.kde`.
https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
Comment 31 sourcemaker 2023-08-22 11:27:35 UTC
Is KDEHOME still in use?
Comment 32 Artem S. Tashkinov 2023-08-22 13:43:58 UTC
(In reply to Martino Fontana from comment #30)
> Adding to this, there's also the `KDEHOME` directory, which defaults to
> `~/.kde`.
> https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy

This article applies only to KDE3 and KDE4. ~/.kde[0-9] hasn't been used for ages.
Comment 33 Alex 2023-09-08 03:34:43 UTC
(In reply to Nate Graham from comment #1)
> This seems reasonable to me.
> 
> Probably a KF6 topic though.

Since, as you mentioned in your blog post [1], the soft freeze for Plasma 6 is coming up, does this still have a chance at moving forward this cycle? It would be nice to have a cleaner separation in `~/.config`.

[1] https://pointieststick.com/2023/09/06/september-plasma-6-update/
Comment 34 Artem S. Tashkinov 2023-09-08 09:26:10 UTC
Nate,

Would be great if you looked into it. The time is running low.
Comment 35 Nate Graham 2023-09-08 17:03:54 UTC
I don't have the time to work on this for Plasma 6, nor the motivation to make the time for it by re-arranging priorities. As I've said before, it's an extremely niche feature that only affects a subset of a subset of people. Someone who really cares about this is probably going to have to be the one who makes it happen.
Comment 36 Artem S. Tashkinov 2023-09-08 17:32:23 UTC
(In reply to Nate Graham from comment #35)
> I don't have the time to work on this for Plasma 6, nor the motivation to
> make the time for it by re-arranging priorities. As I've said before, it's
> an extremely niche feature that only affects a subset of a subset of people.
> Someone who really cares about this is probably going to have to be the one
> who makes it happen.

If no one on the KDE dev team is willing to tackle this issue you may as well close it as WONTFIX and be done with it. It makes no sense to keep it open because once KDE6 is released, no one will touch it until KDE7 development process begins which will probably happen 6 to 10 years from now.
Comment 37 Nate Graham 2023-09-08 18:01:07 UTC
It can be done in an incremental fashion whenever anyone wants, due to the existence of fallback logic in KConfig. There's no pressing need to do this for Plasma 6.0.
Comment 38 Felix Miata 2023-09-08 18:11:17 UTC
(In reply to Artem S. Tashkinov from comment #32) 
> https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
> This article applies only to KDE3 and KDE4. ~/.kde[0-9] hasn't been used for
> ages.

That's its use ever ceased is a tragedy. The move, if done at all, should have been to ~/.config/kde. KDE made an absolute mess of ~/.config and users' backup/restore processes. Fixing this should be high priority, and delay KDE7 as long as it takes to fix.
Comment 39 Nate Graham 2023-09-08 18:18:07 UTC
Sorry, how does it impair backup processes? I back up my whole home folder every day and haven't seen any problems caused by the lack of this issue. Can you explain the impact you're seeing?
Comment 40 Felix Miata 2023-09-08 18:36:35 UTC
People with any sense don't restore * when they find they only need one app's files or one file. That's ripe for expensive loss of totally unrelated data. It's basically the same issue as wanting to clean out everything related to KDE, making that user in effect a virgin KDE user. Not all of ~/.config/[K,k]* is KDE, or [P,p]* Plasma. Determining how or what to select for selective extra/special backup or any restore is a painfully troublesome ordeal.
Comment 41 tagwerk19 2023-09-08 18:58:34 UTC
I remember a bug (somewhere) about needing to separate "configuration" and "state". As I remember this was recognised as an issue and the work was gradually happening. It's worth a nudge of encouragement...

I think the aim is...

If you want to save how your KDE looks and works, you'd save the configuration. If you want to roll back to your initial setup, you'd delete the state. I'm guessing you should never really need to delete the cache, but well, you could and it shouldn't change much...

There's been some discussion on the Nixos forums about what would be needed to manage configuration deterministically and reproducably, I'll see if I can find the reference. There's an admission that there's something of a knowledge gap - not many people know both Nixos and KDE - but here seems to be a focus.
Comment 42 Artem S. Tashkinov 2023-09-08 20:21:22 UTC
(In reply to Nate Graham from comment #39)
> Sorry, how does it impair backup processes? I back up my whole home folder
> every day and haven't seen any problems caused by the lack of this issue.
> Can you explain the impact you're seeing?

Backing up KDE configuration has never been an issue.

Cleaning KDE configuration up has always been an issue.

In multiple KDE related topics on the internet and even this bugzilla people have been recommended to reset their KDE settings to try to fix bugs.

With how configuration files are stored right now, it's near impossible to do that without nuking the entire ~/.config directory which is home to many other applications settings.
Comment 43 tagwerk19 2023-09-08 20:25:54 UTC
(In reply to tagwerk19 from comment #41)
> ... I'll see if I can find the reference ...
Try:
    https://discourse.nixos.org/t/how-to-configure-kde-properly-in-nix/21362
Shows that others are also grappling with this.
Comment 44 alexmateescu 2023-09-08 22:21:53 UTC
(In reply to Artem S. Tashkinov from comment #42)
> (In reply to Nate Graham from comment #39)
> > Sorry, how does it impair backup processes? I back up my whole home folder
> > every day and haven't seen any problems caused by the lack of this issue.
> > Can you explain the impact you're seeing?
> 
> Backing up KDE configuration has never been an issue.
> 
> Cleaning KDE configuration up has always been an issue.
> 
> In multiple KDE related topics on the internet and even this bugzilla people
> have been recommended to reset their KDE settings to try to fix bugs.
> 
> With how configuration files are stored right now, it's near impossible to
> do that without nuking the entire ~/.config directory which is home to many
> other applications settings.

This guy gets it. But it does him no good since the devs don't :(
If KRunner or Kate misbehave, knowing you can go to ~/.config/kde/krunner or ~/.config/kde/kate and get rid of custom configs can go a long way in getting rid of some problems. It can possibly help pinpointing some problems, too, but that wouldn't be helpful since KDE devs are usually unable to reproduce anything even when given step by step instructions for 100% reproducible bugs.
Comment 45 brenbarn 2023-09-10 03:23:42 UTC
Is it absurd that this problem has existed for so long.  As far as I can tell there was never any reason for the disorganized structure of KDE settings.  It makes it very difficult to transfer settings to other computers, across a backup etc.  This should be a much higher priority than a bunch of pointless UI tweaks to make things look glitzier.
Comment 46 Dashon 2023-09-10 03:31:11 UTC
I am subscribed to this issue to get emails regarding work on this issue. I am not here to be spammed by people ranting about how other people choose to spend their time.