-19

b00rt00s wrote: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.

I like this. It's actually natural when you want to:
1. have all of kde grouped together
2. have plasma settings separate from all other apps, since they are less essential for the desktop experience
3. keep it simply by treating every app in kde equally

Right now 1. and 3. are true, but 2. isn't.

What I hoped from supporting this brainstorm idea wasn't actually that the idea itself is implemented, but rather that
a) We agree on that resetting the workspace involves dangerous actions right now.
b) if a) is found to be true, what are feasible solutions?

I think the idea of moving alls app dirs into ~/ was rejected. I can see why. But this is just one of the possible solution for a). Maybe its better to start over in a separate forum thread for a) and go from there.

What do you guys think?

Fri13 wrote: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.

Why would anyone want to get rid of ALL their computer data if they didn't have to? There's nothing easier about grouping everything and having to dig through several folders to find a few single applications data and configs. When a person tells you to rename/move your .kde directory to fix the system, rarely is it mentioned that you'll lose all of your computer data when you do so. This is a huge flaw with KDE. I highly doubt anyone wants to tackle messing with moving all of those applications config folders, most techie linux people just think "People will figure it out", but from a user perspective it's not a good idea.

What is easier? To click the "show hidden files" and locate the folder labeled with an applications name. Then it's just a right click to compress or move the folder to another system's home folder if the user wishes to.

or

Click "show hidden files", search through the .local .config and other folders before they finally find that .kde/share/apps and config are the places they need to look. Search through the multiple obscure developer named files and folders, trying to guess and pick out the important known applications such as amarok and kopete. And then having to save those folders while still mainting the URL path so you have to save them as .kde/share/apps/$folder.


If you save each applications data in it's own folder that's clearly visible in the hidden folders of the home directory, then at least you will know what you're deleting. Right now, KDE has everything hidden away and broken up so when doing anything with the .kde folder, users are shooting themselves in the foot without even knowing it.

@Maik: You could make a forum thread, but many of the KDE developers rely on the mailing lists to discuss things.

Why would anyone want to get rid of ALL their computer data if they didn't have to? There's nothing easier about grouping everything and having to dig through several folders to find a few single applications data and configs. When a person tells you to rename/move your .kde directory to fix the system, rarely is it mentioned that you'll lose all of your computer data when you do so. This is a huge flaw with KDE.

Because people have sessions saved, autostarting applications or problems with plasma + application(s) combinations.

In big problems it is really very easy to check is the problem on newly released KDE SC packages or wrong configurations by renaming .kde4 to other and then relogin. If everything works, then it is easy to delete new .kde4 and rename the old .kde4 back and then change plasma or application configs.

_Many_ times I have found situation where it was best to test first is user .kde(4) configs the reason or were the reason even on system side.

What actually is unsolved and problematic is the current plasma configuration style to push all configs to one file. And there is a brainstorm about that here.

It would solve correctly everything what is talked here as well.

And .kde is great for backup or sync plans. Like example I like to sync my applications configuration between two laptops and computer and it is very easy as I only need to sync the whole .kde4/share/config and execlude plasma* files.

scattering all apps configs to ~ is not answer anyway and brings just problems.

BSmith1012 wrote:

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.

The location of configuration files have been discussed in the Linux community. I will limit this to application configuration, since this is the original suggestion and to keep this simple. I'll also avoid the default configuration files because they also have multiple locations, and things can vary by Linux distribution and even version. Also, Microsoft, Apple, and other operating systems have dealt with these issues as well in surprisingly similar ways.

Previously, these configuration files for each user have been placed in that user's home folder with each application placing the file wherever it seems appropriate.

After some time, it became general consensus or the best practice to place these files in the home directory commonly referred to as ~/ which is shorthand for /home/{username} where {username} is one's log in name. If an application had multiple configuration files, the application would have a directory ~/{application} where {application} is the application name or a unique shortened name for the application.

This is what I call the old way.

KDE took that and created it's own directory and put its configuration files in its own folder called kde. As KDE rolled out updates it created a folder for each version, so that a in KDE 3 a user would have a folder called kde, kde2, and kde3. When KDE four came out, it went back to one folder and it was the commonly known hidden folder ~/.kde.

I call this the KDE way.

Meanwhile, the rest of the Linux community decided to place these configuration files in a specific hidden folder called ~/.config which is considered the standard, not just general consensus.

I call this the new way.

Most developers and programmers have followed this consensus. Gnome does, and Google proudly states that Chrome follows this convention. Strangely, Akonadi follows this convention while other KDE applications still do not. There are still some older applications like Emacs and newer ones like Firefox that still use the ~/ folder for configuration files, but they are the exception.

KDE has a config folder under ~/.kde/share while it still has another folder ~/.kde/share/apps to store still more application data. It does not matter if you have installed KDE or just a KDE application. These files do not need to be there. Even the file manager is not integral to KDE because it no longer handles the desktop.

There is no reason for KDE to keep this legacy set up. KDE can keep its desktop and window manager files in ~/.kde because it's better than the Gnome approach. However, KDE should follow the convention or standard of placing application configuration files in directories under ~/.config in my opinion. I believe this is in line with the intent of the original suggestion, while following a standard that creates consistency.

By the way, how do I vote on this suggestion? Nothing indicates that it is closed. Since I can comment, it obviously is not. Is this a member level thing? If it is, I don't see why any registered member at any level shouldn't be able to vote.

voting is locked, indicated by the lock icons at the ends of the green and red vote bars

There is a big chance that kde frameworks 5 will bring the end to .kde directory.

Akonadi uses .config and .local/share because it was meant to be environment agnostic, that is, there were hopes that the gtk/gnome side will adopt the technology.