Session management and metacity (nargery)

Metacity has a directory ~/.metacity which it uses to store session state. When you log out of GNOME, Metacity stores away a bunch of data about the windows of session-managed applications so that when they start up again it can attempt to restore them. (For example, if you were running Epiphany maximised when you logged out, you probably want it to come up maximised when you log back in.) This is how it’s been done since the early days.

It has been pointed out in GNOME bug 518596 that using ~/.metacity for this purpose is contrary to the freedesktop specifications. This would mean that everyone’s home directory was slightly less cluttered. bkor and others are suggesting making this a Gnome Goal across the whole system.

The question then arises whether session state is a “config” or a “cache” file within the meaning of that specification. Window placement is “non-essential” and to some extent temporary, so perhaps it’s “cache”. On the other hand, it’s not information that can be regenerated with greater effort and is stored to save the trouble, and it is used in configuration, so perhaps it’s “config”. I am writing this post to ask you your opinions on the matter and to lazyweb for prior art.

If we do decide it’s cache, it’s possible we could avoid searching ~/.metacity if the file isn’t in ~/.cache/metacity. That’s good, because that step would stay with us for ever, and I doubt most people keep useful session management files around for more than a few months.

3 Responses to “Session management and metacity (nargery)”

  1. Michael Schurter writes:

    “I couldn’t figure out how to post on your blog, sorry.

    Metacity’s state is most definitely a config file and *not* cached
    data. Window state is a user preference that implicitly set. Just
    because it is set implicitly (via arranging windows) vs. some sort of explicit mechanism (a preferences window) does not mean its cache data.

    HTH :) “

  2. […] bug 518596 – should we not have a .metacity directory? If not, what should we have instead? A post is forthcoming on this blog on the […]

  3. The arguments you’ve put forth regarding the difference between cache & config made me doubt my initial assertion, but Michael’s comments above seem to frame the issue in the most logical way. That is to say, these are settings. I chose to make the window this size and at this place, and, if it needs to be restored, the most logical assumption is that it should be restored to whatever it was before.

    So yeah, if the session information is to be stored, then it should be considered the same as a user-set preference, which I am guessing is a “config”.