GNOME Bugzilla – Bug 518596
Get rid of .metacity and follow fd.o specifications
Last modified: 2008-03-27 17:40:57 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
I agree. We actually only use it for storing session data anyway.
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").
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.
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...
Martin > see bug #518587 I was in my XDG mood :-)
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.
(for smallish values of "all apps"; some apps don't play well with SMs. Firefox, I'm looking at you.)
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.
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.
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
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)
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.