Re: RFC GnomeGoal #3

[Federico Mena Quintero <federico ximian com>]

On Fri, 2006-08-11 at 11:22 +0100, Bastien Nocera wrote:

> I've written up on GNOME Goal #3:
> http://live.gnome.org/GnomeGoalsSaveState
> 
> Currently, a lot of applications will be using GConf to save state, like
> window sizes, whether or not a window is maximised on startup, etc.
> 
> This is against GConf policy, as GConf might be read-only, or locked
> down, but this sort of information should still be saved run-to-run.

This is often misinterpreted:
        
        Do not store anything but preferences in GConf. Documents,
        session state, random data blobs do not belong in GConf. Stuff
        breaks if you do this. Moreover, THERE IS NO GUARANTEE THAT IT'S
        EVEN POSSIBLE TO WRITE TO THE GCONF DATABASE. Which means you
        may not use GConf as an IPC mechanism or when it's required to
        be able to store a piece of data.

The very act of wanting to preserve the user's window geometries means
that you are storing user preferences.  Let's not make a semantics
argument out of this.  GConf *is* the GNOME way of storing
configuration-like information, and so the user's window geometries
should live in GConf.

Lockdown is not an issue.  Once we have a real lockdown API, we can have
a gnome_lockdown_is_user_allowed_to_persist_window_positions() for the
really really neurotic sysadmins.

If you have a read-only database, then you are in a kiosk and you can't
save *anything* anyway, not just GConf keys.

Finally, Havoc is right:  we need a very high level
save_window_state(window, key) which handles all the details
transparently (including per-screen-size information).

We went to great efforts in the past to make this happen through the
session manager and window manager, but apps still failed to set their
unique window keys correctly.  Let's see how this everything-in-the-app
thing goes; it will certainly be easier to debug.

  Federico