Hm… I guess I meant “you can’t do this *now*, without breaking things”, not “you can’t do this at all! you have to maintain that code FOREVER BWAHAHA”. :)

Well, that was rather the point: the two people who I know to have suggested this think XSMP is poorly designed, so they don’t really mind what it says we should do.

Taking the fifth option would presumably require checking that all major applications (that we had some control over) were capable of restoring their windows correctly. gedit would certainly fall into this category.

(I only made the mental connection the other day that having the WM deal with this means that everyone has a huge list on disk of the titles of the webpage they were looking at when they logged out or their laptop ran out of power, since that’s kept in the window title. That’s presumably something that a browser might want to do differently, but the WM can’t know any better.)

You can’t abolish session management *just* within the window manager, because XSMP says the window manager restores window positions, so if you don’t, then session management won’t work right. Eg, I know for sure that if you resume a saved gedit state without having metacity resume its window positions, that you will end up with all of your gedit windows being 200×200 (the default size for a GtkWindow, which is much too small to be useful for gedit). I’m not sure how other apps behave; some might at least default to a reasonable size, if not the actual correct size.

As for having apps remember their own state, there are two levels of that. On the one hand, there’s “apps should remember a default window size” and/or “apps should remember the window size the user last used for a given document”, and apps can already do that, and I think there’s a reasonable amount of agreement that they *should* do that as well.

On the other hand, there’s full-blown session state saving of the sort that allegedly happens when you save-session-on-logout now, where you’re trying to restore not just window size, but actually the exact global arrangement of all windows that you had previously. This is something that it’s not possible for apps to handle entirely on their own currently, because in some WMs, it’s not possible for apps to figure out everything that the window manager considers relevant to their position. (In particular, IIRC, in a WM that uses large desktops rather than multiple workspaces, there’s no reliable way for a newly-launched app to request to be launched outside the current viewport. Likewise, if the WM offers any clever functionality beyond what the EWMH discusses, like pinning to some-but-not-all workspaces, there’s no way for a window to generically be able to figure out that it’s in that state and then restore it correctly later). There are also other things that it’s theoretically possible for the windows to figure out on their own, but that it’s much easier to get right if the WM is playing along too. (Eg, getting the window stacking order correct.)

One argument is that this latter sort of state saving is crack and we don’t care. OTOH, if we *do* care, then one way to fix it so that apps can save and restore their own state would be to add a new EWMH hint, say “_NET_WM_WINDOW_STATE_ATOMS” or something, which the WM would set on a window, to a list of other atoms. And when the app wants to save its state, it would just fetch the values of all of the atoms listed in that property, and save their values, and then later on when it wants to recreate that state, it just creates a new window with all of those atoms set to the saved values.

As you stated, there’s currently no good way of doing it, and the code in Awn that deals with this has had many extra matching rules bolted on it over the past year. This is something which I hope to rewrite in the next few months, but I’m dreading it as there is a high chance of introducing regressions. It would be great if there was a sane way of doing this, without lots of application-specific special casing.

Devil’s Pie does something separate to what Metacity does here. This article is about how Metacity places windows when you log in. Devil’s Pie has the ability to arrange windows when you open an application at any point; the article is not about that.