-19

Many times in the past I have had to delete my KDE configuration folder when I had issues with my computer. This folder is either a ".kde" or a ".kde4" folder located in the home directory. If you've never seen this folder, it's because you have to enable "Show Hidden Files" in Dolphin for it to become visible. The .kde folder is the main location of all of your KDE specific configuration files. Unfortunately, for some reason, developers have used this configuration folder to hold not only KDE system configurations such as the panels, layouts, recent files, etc.; but also to hold the configurations for KDE applications. This means that the configurations for Kopete, Akregator, Dolphin, Kontact, Amarok, Digikam, and many others are all stored together in this one folder. I find this alarming because one of the most recommended fixes for a problem with KDE is to delete your .kde folder. Doing this will erase your custom system settings that most likely were causing the problem, but it will also destroy all of your settings for every KDE application you have installed as well.

In order to address this issue I believe it would be better for KDE to take out certain applications' configuration folders from within the .kde folder and to create their own standalone folder within the home directory. This is already done for 3rd party linux applications such as LibreOffice, Firefox, Thunderbird, Skype, and many others. This way, an issue that would cause KDE to fail to load the kdm and cause the desktop to be unusable could be fixed by deleting the .kde folder and do so without completely destroying all of your data in many popular applications as well.

To show how this would look when browsing your home folder, here's two screenshots; the first showing my normal home directory with all KDE configurations in one folder, and the second screenshot showing several highlighted folders for popular KDE applications that could be given their own central configuration and user data folders.



This idea was originally posted on my blog.
http://bsmith1012.blogspot.com/2011/03/ ... ation.html

You shouldn't delete your .kde or .kde4 folder when trying to debug problems, you should rename it.

Your approach would make it much harder to debug problems, since the user would have to rename dozens of folder instead of just one

TheBlackCat wrote:You shouldn't delete your .kde or .kde4 folder when trying to debug problems, you should rename it.

Your approach would make it much harder to debug problems, since the user would have to rename dozens of folder instead of just one

No... You should reread my proposal. The whole point is to decouple KDE system configurations from KDE application settings and data. Which would make it much EASIER to debug problems, as you wouldn't want to "rename" dozens of folders when the problem is only in one of them. No bug in Amarok, Kopete, or Digikam is going to create a black screen on startup or create issues that prevents the user from logging in. Therefore, just like firefox, thunderbird, and others, those application folders shouldn't all be bundled in with system settings that might cause catastrophic system failure. The .kde folder would still be there, but it's removal would no longer destroy perfectly fine user data and settings for applications.

Instead of chopping down the entire tree when you have one dead branch, this would allow you to more easily get rid of the bad files while keeping those that are still useful.

But those directories are separated already. They are in ~/.kde4/share/apps and ~/.kde4/share/config. I would rather suggest to merge files in these two directories so everything connected with one application would be in one place.

If you see a 'rm -fr .kde' advice somewhere (in this forum or anywhere else), please immediately post a reply to notify the poster that that solution shouldn't be used, not ever. (and notify the board admin to censor/change it if the poster doesn't)

-----

The config files and app data are separated into
.share/config/${appname}rc
and
.share/apps/${appname}

So those are already separated enough not to need to /fix/ things by removing the whole .kde dir.

1 Problem definition
---------------------

1.1 Summary of the following
=============================

The simplicity of having just one dir that contains all the users kde
data is outweight by the risks that come with it. It's too easy to
accidentally delete irrepressible user data during simple debugging
sessions.


1.2 A closer look
==================

I think it's a good idea to point out where the simplicity of having
all settings and data of all KDE SC apps within a single directory
shines and where it falls short.

I assume that the location of settings and data only becomes relevant
to a user if there a problem to debug.


1.2.1 Finding a bug
~~~~~~~~~~~~~~~~~~~~

* Make sure kde works with default setup

The use case where it shines the most is during one of a 4.n ->
4.(n+1) upgrade. The first step in debugging problem here is to
figure if kde run properly in its default configuration. This is done
by simply renaming ~/.kde. That's very easy to communicate via IRC
etc .

If problems occur with this reset kde we've saved our self from
spending hours and hours of guessing.


* The actual analysis

Given that it works fine, we can further investigate. The following
partitioning of problem sources is useful at this point
- kwin
- kde-workspace (plasma)
- standalone kde app

If kwin fails, then the the workspace and all standalone apps inherit
this problem. If the workspace fails, then all standalone apps
inherit this problem. If a standalone app fails it doesn't effect the
workspace and other apps directly.

Hence the problems with standalone apps are of lower priority. Given
that kwin worked fine with a fresh .kde it's unlikely to cause
problems, from my experience, since it doesn't load 3rd party code
unlike plasma. Hence it makes sense to concentrate on plasma [1].

We can do two things now
- copy the old plasma settings and plasmoids into the fresh ~/.kde
dir and see what happens
- remove/rename the fresh ~/.kde dir, rename the .kde_bak to .kde and
remove/rename the plasma settings.

I bet most of you are familiar with plasma issues and that the fasted
way to figure problems it to remove the plasma setting files and add
one plasmoid after another.

What I've omit to mention so far is that one has to shut down kde/kdm
completely before ~/.kde is renamed. The same works for working with
plasma files, but it sufficient to just shut down plasma-desktop and
start it again afterwards.


1.2.2 The problem
~~~~~~~~~~~~~~~~~~

There is alot that can go wrong during the renaming and removing. The
least of the problems is loosing the plasma and kwin settings. The
horror scenario is if a user accidentally deletes data that isn't easily
reproducible i.e.: kopete and kmail data.

Considering that the vast majority of the apps don't cause any
trouble, but just plasma, it troubles me to touch the dir that their
settings and data live in at all.

What we want (IMHO) for debugging purposes is this

- easy way to test if a clean kde session runs
- easily reset non standalone app settings (plasma, kwin, ..)

These two points are take care of by having ~/.kde contain everything.

What we don't want is:

- Touching dirs that contain user data that isn't related to the
problem at hand.

And this is where having everything within ~/.kde falls short.

2 Possible solutions
---------------------

TODO

[1] It might sound like I dislike the way plasma is designed or
implemented. That's not the case. It's just the heart of the kde
experience and can fail at any time by loading buggy binary plasmoids.

@b00rt00s: That is an issue as well. If you do have to get rid of the .kde folder, you will have to find application files you wish to save in both of those places. Having a central location in the home directory would make it easier to remove or backup an applications settings and data.

@ivan: I understand you're point but you may not be taking into account people who aren't as familiar with KDE. A new user would not know how to go through and pick out the folders and files for their applications so that they can still keep their data. So if they were told that they should rename their .kde directory, that's what they will do, and most likely they wont know how to get their kopete, kmail, amarok, dolphin, etc. settings and data back. You're looking at it from a developer or heavy user pov, but what about those people who just want to use kde and not have to get into all that messy technical stuff. Should they lose all of their emails and chat history and torrents just because we decided bundling kde 'system' settings and kde 'application' settings wasn't an issue? I think its an obvious flaw the way it is now. Maybe if there was two folders in the main .kde files, one "system" and one "apps", that might work. But having them all mixed in together and forcing the user to recognize configuration files and have to make the decision for which ones to keep with no experience or expertise, isn't the best solution. I've personally lost data several times in the past before I was able to learn enough to pick through those folders and files. Not every KDE user will want to figure that out though, and not everyone SHOULD have to figure that out.

@Maik: I completely agree with your summary! Thanks for taking the time to go through the points.

Btw. rather than having a dir for each app in ~/
~/.foo/
which causes a lot of noise in ~/, I'd suggest
~/.local/share/foo
for the data and
~/.config/foo
for settings.

Maik wrote:Btw. rather than having a dir for each app in ~/
~/.foo/
which causes a lot of noise in ~/, I'd suggest
~/.local/share/foo
for the data and
~/.config/foo
for settings.

You know, I still like my solution, but for the interest of compromise I'd be willing to say that that would work. Because the main issue is to separate the system files from the application files.

Edit: One central place for both applications data and settings might be an argument to have as well though.

If you want a quick and dirty implementation of Maik's solution, just do
ln -s ~/.config ~/.kde/share/config
ln -s ~/.local/share ~/.kde/share/apps

(naturally, you'd need to transfer the current data to .local and .config first)

if you do a rm -fr .kde with this setup, nothing but symlinks get deleted - so no screwups while it retains the easy 'clean user' debugging method.

I think people are scared by the idea of changing the directory structure, since it is the potential source if many problems.

I see several discussion topics that this idea can be broken into.

1. What are the common tasks when debugging workspace problems?

2. How likely is it for unexperienced users to accidentally delete their apps data while debugging kde workspace problems? Is it too likely?

3. How likely is it that even experienced users accidentally delete their apps data while debugging workspace problems? Is it too likely?

4. Given that 2. and/or 3. are found to be true, what are possible solutions?

4.1 Solution #1: Your suggestion: Separate Configuration Folders For KDE Applications

4.1.1 What are the side effects:
This potentially breaks working code. Would this be justified?

4.2 Solution #2 ...

ivan wrote:If you want a quick and dirty implementation of Maik's solution, just do
ln -s ~/.config ~/.kde/share/config
ln -s ~/.local/share ~/.kde/share/apps

...

if you do a rm -fr .kde with this setup, nothing but symlinks get deleted - so no screwups while it retains the easy 'clean user' debugging method.

It still doesn't separate the app form the workspace data, but it is an improvement.

(I use the term workspace data here for anything that doesn't belong to standalone apps).

EDIT: To have rm -rf .kde do no real harm it would be even quicker to just do
mv .kde .$USER-kde
ln -s .$USER-kde .kde

ivan wrote:If you want a quick and dirty implementation of Maik's solution, just do
ln -s ~/.config ~/.kde/share/config
ln -s ~/.local/share ~/.kde/share/apps

(naturally, you'd need to transfer the current data to .local and .config first)

if you do a rm -fr .kde with this setup, nothing but symlinks get deleted - so no screwups while it retains the easy 'clean user' debugging method.

This wouldn't be an ideal solution but thank you for the idea. I know how to pick through the .kde folder now so my idea was more for new or not as advanced users.

BSmith1012 wrote:
This wouldn't be an ideal solution but thank you for the idea. I know how to pick through the .kde folder now so my idea was more for new or not as advanced users.

The problem with .local and .config is that if we did that, the forum posters would probably start recommending a 'rm -fr .local .config' fix for problem

The ln -s thing would prevent deletion of the actual data while not changing the current 'rm' practise. Distros could probably pick that one up.

So, in essence, everything has its pros and cons

I dont find any problems with .kde(4)/share/config and .kde(4)/share/apps directories.

It is much better that every KDE application is officially located to .kde(4) directory and not to home directory (~).

As right now, user can easily specifically rename/move (not delete!) all application configs or/and all KDE Platform configs if needed.

The current system allows groupping, the idea to push every application to ~ alone just scatters everything around.