Gnome Q: Application window save-data for restore when reopened?

[夜神 岩男]

On Sun, 2011-07-03 at 12:04 -0700, Daniel B. Thurman wrote:
> I am sorry if this question was asked before,
> but I was wondering why is it, that most app-
> lication's main window do not restore it's
> last save-data the next time it is opened?
> What I am talking about is window position
> and size data, but not limited to these only.

This is an issue that exists per-application. It has been possible to
have an application remember its most recent settings for as long as I
can remember, and that detail has been overlooked by most new projects
in their first few iterations for as long as I can remember.

> How many times does an application have to be
> repositioned & resized every time it is opened?

42.

> Further, is there a Gnome application design framework,
> that includes built-in support for application save-data
> which include things as position, size, workspace location
> session-save hooks, and any window specific save-data
> so that designers will automatically have this code when
> developing new windows applications? (Yeah, dream on?)

This already exists. Most people writing their first app just don't
focus on this sort of thing, and the issue often goes overlooked for a
very long time before someone in the upstream project realizes "Bagh! My
highly useful application is really irritating to resize all the time!"

> It would also be nice if this was standardized, so that a
> Desktop configuration tool would recognize these apps
> and allow for Global & User property changes saved
> either in the the global or user's (~/.config "database")
> or whatever is appropriate.

This would be very difficult to implement because it would require
crystal-ball technology. How would a global settings file/function
anticipate the creation of all new apps, window libraries and possible
locations in the future and make a slot for each of them?

The standardish way of handling this (and this is the same on Windows,
OSX and our Linux constellation of window managers) is to have the
application record its last state in a file somewhere in the users home
directory. Usually if you go hunting through your dot folders you can
find current state data or cumulative data for an app inside an XML or
other data file in there somewhere.

A good open source example is X-chat's ~/.xchat2/xchat.conf file.

A good example in a multi-platform closed source app would be Skype's
~/.Skype/shared.xml file.

Whenever an application doesn't behave like this, it is usually the
fault of the application, not the window manager. The place to focus
your attention is upstream. Either patch the application to add this
sort of functionality (fairly easy to do if you've got experience, and
if not a good way to start learning the libraries involved in your
favorite apps), or bug upstream to do it.