Re: RFC GnomeGoal #3

[Shaun McCance <shaunm gnome org>]

On Fri, 2006-08-11 at 16:04 -0500, Federico Mena Quintero wrote:
> 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.

The reason an app needs some control over this is that
not all windows are created equal.  I don't think all
windows should be storing both window size and window
position.  I remember sending an email something like
this to the usability list once, but I don't feel like
hunting for it.

Nautilus (spatial) [one-to-one]
  Nautilus has one window per "object" (in this case,
  per directory).  This reinforces a window-is-object
  model, and it should remember the size and position
  on a per-object basis (as it does).

Epiphany and Yelp [many-to-many]
  Windows are used for browsing, so no single window
  corresponds directly to any particular object.  Many
  windows are often used, with no discernable means of
  distinguishing what they're for.  Users tend to put
  these windows wherever happens to be most convenient
  at the time, so storing window position will rarely
  be helpful.  Storing window size won't be perfect
  (think of the occasional resize for badly designed
  sites), but it's better than nothing.

Evolution [one-to-many]
  The application stands on its own, and users will
  typically only have one window open.  Because users
  don't have lots of them hanging around, window size
  and position can be stored as a global (unlike the
  per-object storage for Nautilus).

Basically, I think that whether to store various bits
of state, and how to store them, depends entirely on
how your application is used.  Doing this well means
giving application developers the ability to control
this.

--
Shaun