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.
This seems reasonable to me. Probably a KF6 topic though.
*** Bug 422920 has been marked as a duplicate of this bug. ***
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?
(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.
*** Bug 430425 has been marked as a duplicate of this bug. ***
(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.
*** Bug 460400 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
(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.
(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.
(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.
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?
(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.
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.
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.
(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.
(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.
(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.
(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.
(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.
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?
Hey, that sounds like an eminently sane plan to me. I say go for it!
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.
(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
@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.
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.
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.
Adding to this, there's also the `KDEHOME` directory, which defaults to `~/.kde`. https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
Is KDEHOME still in use?
(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.
(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/
Nate, Would be great if you looked into it. The time is running low.
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.
(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.
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.
(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.
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?
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.
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.
(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.
(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.
(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.
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.
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.