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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
