I'm going to say this here instead of in tons of bugs.

Before we start moving all kind of stuff from ~/.gnome2/ to ~/.config/, we need to discuss this. This causes migration problems, compatibility problems, etc. We have to be careful.

Vuntz : but what about the principle ? Do we agree that moving to $XDG_* is a good idea and necessary ? (I think so but I don't know if it's a consensus)

If yes, then of course there are a lof of problem but most applications will handle it theirselves. (It might be tricky for some other) In other words : it's then only a technical problem. 

Also, I want to insist that this is *not* about putting .gnome2/* in .config. It's a lot more subtle than that and it's about well separating user data and user preferences. I think it's really important to insist on it because if not understood perfectly, it will not solve anything. Only one application that doesn't understand this and put data in .config and all the process is broken. (You have to think all the time that .config could be deleted completely at any time in order to restore the default preferences. That's unlike .local)

(In reply to comment #2)
> Vuntz : but what about the principle ? Do we agree that moving to $XDG_* is a
> good idea and necessary ? (I think so but I don't know if it's a consensus)

I'd blindly agree with moving to the $XDG dir if we didn't have something in place at this point. Right now, I don't know. At least, I know it's not necessary;

> If yes, then of course there are a lof of problem but most applications will
> handle it theirselves. (It might be tricky for some other) In other words :
> it's then only a technical problem. 

No. We should agree on the way to handle this globally and then implement this in all modules.

> Also, I want to insist that this is *not* about putting .gnome2/* in .config.
> It's a lot more subtle than that and it's about well separating user data and
> user preferences. I think it's really important to insist on it because if not
> understood perfectly, it will not solve anything. Only one application that
> doesn't understand this and put data in .config and all the process is broken.
> (You have to think all the time that .config could be deleted completely at any
> time in order to restore the default preferences. That's unlike .local)

Well, to be honest, given the opened bugs, I guess most people will just move from .gnome2 to .config without even thinking what's a setting and what's not a setting... It clearly needs thoughts, and the bugs are not enough for this, unfortunately.

Given what I saw in other bugs (like proposed patches), I agree that the issue needs now more debate, explanations and guidelines.

It was proposed to make this a "Gnome goal" which could help. What do you think ?

Yes, it would make sense to have a GNOME Goal for this.

I've created the corresponding Gnome Goal page :
http://live.gnome.org/GnomeGoals/XDGConfigFolders

I think that the main point of discussion will be "And what about Gconf ?" 

But it's an interesting discussion.

What about that GnomeGoal? Maybe we should make it a little more official.

(In reply to comment #7)
> What about that GnomeGoal? Maybe we should make it a little more official.

I didn't see any discussion on the problems this might cause (see my comments here). So it's not going to be an official goal without this...

I tried to launch the discussion on gnome-love. I tried to send it to gnome-hackers and I'm awaiting moderation.

http://mail.gnome.org/archives/gnome-love/2008-September/msg00000.html

I suggest that people on gnome-hackers who are interested already start the discussion.

*** Bug 588281 has been marked as a duplicate of this bug. ***

Also depends on FreeDesktop Bugzilla – Bug 20411 fontconfig doesn't match FreeDesktop directories

Could this be a goal for GNOME 3.0? Has there been discussion on this [other than on this bug]?

Hi,

I'd really love to see this implemented. It would particularly suit to make it a gnome 3.0 goal, so we start with some cleaned up config/data/cache directories when gnome 3 is ready.

Personally the messed up home directory has always been an annoyance for me ever since migrating from Windows to Linux. On windows this has been solved long ago with the introduction of "Application Data" and "Local Settings" etc which are hidden in the profile folder. Also not all applications make right use of it, it still makes many things easier in windows.

Just my opinion
Cheers

P.S. In addition to the FreeDesktop spec I think is also necessary to remember that applications don't save the default settings into the .config folder. Instead only those options should actively be saved that differ from the default settings -- this would help to keep the .config folder clean.

sbastig@gmx.net: The intention is to implement this (no ETA though). If you can help write patches or can find people who can contribute patches to fix this the various GNOME maintainers would really appreciate the assistance.

@Olav,

the way I understand this is, that this is currently not an approved gnome goal. 
In http://live.gnome.org/GnomeGoals/XDGConfigFolders the message is:
"This should not be applied before being officially turned into a GNOME Goal."

And the bottom line of this bug is: "Dont implement until we approve it as a gnome goal and made sure migration goes smooth.".

So far I have already written 3 patches for (tilda, eog and update-notifier), and plan to write more as I find time. But for example the bug for eog (bug 522806) is blocked by this bug. I would love to write more XDG patches if I could be sure there is a general willingness to merge them, this is why I suggest to make this an official gnome goal for 3.0

There is also another guy who has been writing patches (Christian Klein):
https://bugzilla.gnome.org/show_bug.cgi?id=627939.

So lets mark this bug as confirmed and start discussing about whether or not we make this a gnome 3 goal. I don't think we are short of people who write patches.

Cheers
Sebastian

(In reply to comment #15)
> this is currently not an approved gnome goal. 

There is no defined way how to "approve" anyway hence I wouldn't care... :)

> But for example the bug for eog (bug 522806) is blocked by this bug.

No, it is the other way round.

> I would love to write more XDG patches

It is definitely very welcome!

So how did the other gnome goal get turned into official goals? Is this done during some conference? Or via one of the mailing lists? Could you point me to some more information?

>No, it is the other way round.
Ah ok, then I mixed that up.

André: Approving stuff is a task of the release team.

So:
1. Discuss on desktop-devel-list. Though IIRC there has been some discussion. Best when sending a new msg to summarize the existing stuff.
2. Have decision taken by release-team. #2 really depends on a good discussion at step 1

Note:
* How to migrate from old location to new?
* How long to check if stuff needs migrating?
* XDG means more locations to store things instead of current usage

I have just taken some time to sum up briefly what I could find on different pages, and also created a resources section with the different links. Maybe we can take this as a starting point for discussion about what needs to be done and how?

Whats more I just skimmed thorugh a couple of bugs and found many comments where people write something like this:
[...] I'd like to first have this GNOME Goal "approved" by community
before fixing this bug. [...] (from eog)

--------------------------------------------------------------------------------
* XDG means more locations to store things instead of current usage!
The old configuration files are currently stored directly in the home folder such as "~/.<programname>", the XDG spec proposes to move the files stored in this folder to three different folders based on the type and content of the files. These three folders are ".cache/", ".config/" and ".local/share/" the reasoning behind these three folders is that .cache only contains temporary data which can automatically be regenerated by a program, thus deleting it would have no consequences to the user other than making the program slower (until the files have be regenerated). The .config folder should contain files that store the preference of the user, that is all settings for which the user has chosen a value other than the default value, deleting these files would cause the application to return to the factory setting and allow the user to enter a new set of preferences. Finally the .local/share directory should contain all the data that is unique to the user. This could be instant messaging histories, playlists, emails, temporary backups (such as opened documents) etc.

* How long to check if stuff needs migrating?

The time to check if an application needs migrating is usually very quick, just clone the repository to a local folder
~$ git clone git.gnome.org/<projectname>
~$ cd <projectname>
Then use grep to test for common code samples that are used to save stuff in the home directory such as:
projectname$ grep -R g_get_ * 
(FIXME: what are there others strings to search for?)

If you have the application installed and used it already the it might be sufficient to just check in your home folder if it created any config files.

* How to migrate from old location to new?

This usually needs some individual considerations. But mainly it includes the following steps (might be incomplete):
* Find the code places which need to be changed (see above)
* Consider into which XDG folder the files need to be saved
	* XDG_DATA_HOME
	* XDG_CONFIG_HOME
	* XDG_CACHE_HOME
* Change the code to store (and load) the files to the respective location
* Write a migration handler which checks if old files are present and migrates them to the new location.
* What about that migration handler?
* The part with the migration handler might be a bit tricky. First the old folder contains the files of all three categories, thus the migration function must need to take care to move each file and folder to one of the three categories.
* Second the migration handler needs to check if there are already some files in the new location which might get overridden and then takes steps to prevent this. Depending on the complexity and importance of the files, these steps might vary between printing a short message to stderr or display a dialog on the GUI.
* Resources?
	* The bug which discusses the gnome goal:
		https://bugzilla.gnome.org/show_bug.cgi?id=523057 
	* The GNOME Goal proposal:
		http://live.gnome.org/GnomeGoals/XDGConfigFolders
	* A blog entry about the XDG Spec:
		http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
		http://ploum.frimouvy.org/?207-modify-your-application-to-use-xdg-folders (more detailed)
	* Ubuntu Brainstorm
		http://brainstorm.ubuntu.com/idea/1210/ (current)
		http://brainstorm.ubuntu.com/idea/6557/ (duplicate)
		http://brainstorm.ubuntu.com/idea/9343/ (duplicate)
	* The _official_ FreeDesktop specification
		http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
	* Thoughs of other people
		http://www.aigarius.com/blog/2007/01/10/fhs-extension-for-user-home-folders/
* Show me the Code!
Some common functions to use are:
g_get_user_config_dir()
g_get_user_data_dir()
g_get_user_cache_dir()
these functions are commonly used to replace g_get_home_dir(), which simply returns the home directory.
g_build_filename()
g_mkdir()
g_rename()
g_file_test()
Use "devhelp" from the devhelp-package!
Warning: Dont just blindly replace "g_get_home_dir()" with any of the the three g_get_user_*_dir() functions and hope it will work.
FIXME: add some code samples which illustrate how to do this.

(In reply to comment #19)
> * How long to check if stuff needs migrating?

I meant: Applications MUST migrate their files from ~/.$project and ~/.gnome2/$project to the XDG specs. However, how long should applications keep code to migrate from the old location to the new location? Whole of GNOME 3.x?
There is a lot of focus on startup speed. We don't want to slow down application startup for something like a migration for too long.

The code would have to be kept until the last distribution with an upgrade path to a new version reaches EOL. So for ubuntu or debian this would be around 2 years. For example if the last ubuntu lts version still ships an application without the migration code included and the migration code is added shortly afterwards, then it should be kept until the next version ob ubuntu LTS is released. The reasoning is that you can only upgrade from one LTS version to another and not skip one, thus afterwards its no longer necessary to maintain the upgrade code.

Please add bgo#659104 to the list of depending bugs.

There are currently 81 bugs being tracked by this bug out of which more than two thirds are already fixed and of the remaining 25 may are being worked on currently.

Yet this tracking bug still has the status new and also the goal for this bug is only a 'next goal candidate'. When are we going to make this an official gnome goal? I believe this would give some incentive to the developers to fix the remaining bugs so that we can finally close this bug maybe with Gnome 3.6 or 3.8?

So are we going to mark this bug as confirmed?

(In reply to comment #23)
> So are we going to mark this bug as confirmed?

There is no such state in our bugzilla :-) It's marked as NEW, which is pretty much the same as what you're asking for.

Hi,

Great progress have been made !

What about the /home/.dbus directory : is it still needed ?

Thanks

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all
older tickets in GNOME Bugzilla.

If this is still a valid request in a recent and currently supported version of GNOME, then please feel free to use https://gitlab.gnome.org/groups/GNOME/-/issues and/or (if this ticket is about a general Initiative) check the `9. Initiative` labels on https://gitlab.gnome.org/groups/GNOME/-/labels if they should be applied on codebase-specific tickets in GitLab. Thanks.