After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 518596 - Get rid of .metacity and follow fd.o specifications
Get rid of .metacity and follow fd.o specifications
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.20.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on: 522285
Blocks: 523057
 
 
Reported: 2008-02-25 11:58 UTC by Lionel Dricot
Modified: 2008-03-27 17:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Lionel Dricot 2008-02-25 11:58:15 UTC
Metacity shouldn't create a .metacity folder.

According to fd.o specification, it should put user preferences in
$XDG_CONFIG_HOME.

Any user date should go to $XDG_DATA_HOME.

Any cache stuffs should go to $XDG_CACHE_HOME

More infos : http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html

The reason why I'm reporting this bug :
http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
Comment 1 Thomas Thurman 2008-02-25 12:46:12 UTC
I agree. We actually only use it for storing session data anyway.
Comment 2 Thomas Thurman 2008-02-25 13:14:14 UTC
Okay, so we will look in the directory named by g_get_user_config_dir() for sessions and then in the ~/.metacity for backward compatibility.  That will solve this problem, I think.

http://library.gnome.org/devel/glib/2.15/glib-Miscellaneous-Utility-Functions.html

Are session files cache files or config files?

Someone really needs to spellcheck that fd.o page ("seperated").
Comment 3 Lionel Dricot 2008-02-25 13:47:16 UTC
If deleting them doesn't affect anything, I would say it's a cache. But I'm not familiar with the concept of sessions in metacity.
Comment 4 Martin Meyer 2008-02-25 14:04:43 UTC
With this change, will metacity no longer create that .metacity folder if it doesn't exist? That would make my favorite deity sing and dance and stuff.

Also, can you point to a link (or give a brief description) of what metacity uses its session data for? I'd be interested in hearing what nautilus uses theirs for too, but that's for another time and bug...
Comment 5 Lionel Dricot 2008-02-25 14:10:28 UTC
Martin > see bug #518587

I was in my XDG mood :-)
Comment 6 Thomas Thurman 2008-02-25 14:24:57 UTC
Lionel: bkor is apparently interested in making this a Gnome Goal.  Can you get in touch with him?

Martin: Yes, it won't do that any more.  Briefly (AIUI), when you quit a session governed by the session manager, the SM remembers all apps that were running, including the WM.  When you log back in, the SM restores all these apps, but the apps should not have the responsibility to restore all their window states themselves.  Rather, it's done in one place, the WM: the WM stores a list of what windows were open on session exit, and on session restart it goes through the windows which have been revived and tries to make them as close as possible to before.  I may make a post about this, or it might wait until after the patch is ready (which is mostly already written).

I would like youtube of the dancing deity.
Comment 7 Thomas Thurman 2008-02-25 14:26:18 UTC
(for smallish values of "all apps"; some apps don't play well with SMs.  Firefox, I'm looking at you.)
Comment 8 Thomas Thurman 2008-02-25 16:10:58 UTC
Here's another question:

a) Are these files config or cache files?

b) If they are cache files, it doesn't matter if one time or another we happen to lose them. So backward compatibility is not so important.

c) If backward compatibility is not so important, we don't have to check "~/.metacity" after "~/.cache/metacity/".  This is good, because otherwise we'll have this check in forever even after it's pretty much useless to everyone in the world.

c) If backward compatibility is not so important, we are also able to change the format, so we can consider the advantages or disadvantages (now or another time) of changing from the current rather hacky GMarkup reader to GKeyFile, which would possibly be cleaner and easier to understand.
Comment 9 Luis Menina 2008-02-26 16:18:08 UTC
This topic keeps coming regularly:
http://live.gnome.org/GnomeGoals/SaveState

There was also a talk about this at GUADEC 2007 by Sven Herzberg.
http://www.advogato.org/person/herzi/
http://herzi.eu/

His point was that it was quite difficult to have window location right, and explained how to have it done in an app. But if a default working policy in metacity would be the best that could happen. Maybe you could contact him about this, and maybe push an RFC about this in d-d-l, to finally have a consensus on this hot topic...

Oh, and I totally agree with the reply of Michael Schurter on your blog: this really shoud be configuration, not cache.
Comment 10 Thomas Thurman 2008-03-27 13:14:24 UTC
I had the idea of taking advantage of this opportunity to do a huge rewrite of the save file system and fix a lot of its infelicities, but there's a lot to do, this can be fixed with just a few lines, and we don't even know that WMs will continue to play a part in SM.

Fixed.
http://svn.gnome.org/viewvc/metacity?rev=3666&view=rev
Comment 11 Vincent Untz 2008-03-27 15:00:44 UTC
Thomas: see the discussion in bug 523057. I'm not 100% convinced this should be done now, without a desktop-wide agreement on how to do it. (I see you have some compatibility code, which is good, so maybe you can safely ignore my comment)
Comment 12 Thomas Thurman 2008-03-27 17:40:57 UTC
Vincent: Thanks for the heads up.  I'm not overly concerned whether the code goes in ~/.gnome2/metacity or ~/.config/metacity, as long as it doesn't go in ~/.metacity.  If we're not going to stay with ~/.config across the desktop, g_get_user_config_dir() ought to be returning ~/.gnome2 anyway, I think, so it's a library problem rather than something Metacity needs to deal with.