Re: how to store prefs/session data

[Glynn Foster <glynn foster sun com>]

On Wed, 2001-10-10 at 06:21, Havoc Pennington wrote:
> 
> Hi,
> 
> Appended is an earlier mail outlining the issues of prefs/session
> data. This mail is what I think we should do, as a proposal.
> 
>  A. Only settings related to window sizes/positions, application 
>     _instance_ state (e.g. currently open document), 
>     and display size, should be stored per-session. 

I think it's important to note, that as an application developer, you
should not try and save the window position because that should be
handled by the window manager. However, if an application has internal
windows ie. tiled windows horizontally/vertically then the application
should have to handle these positions and then should indeed be stored
per-session.

As far as the panel is concerned, which I'm most concerned about right
now, is that should launchers, applets, number of panels, menu items be
stored per-session. I think I'm 60/40 in favour of them being so but
there are always going to be exceptional cases where it doesn't make
sense.

>     Rationale: the session is a canned setup for a particular 
>     display or task. It is not a canned set of preferences; 
>     preferences span application instances.

Agreed....but sometimes it's difficult to interpret the rules :)

>     You CANNOT implement saving 
>     the session by pushing a different config prefix onto 
>     your standard prefs-saving code.

I'm not quite sure I understand here...

>  C. There is nothing wrong with storing per-session state in flat 
>     files or whatever rather than gconf.

Nothing wrong no, but for consistancy's sake we should encourage a
single configuration mechanism [if possible] and also to avoid
confusion. Especially if it means that we don't have to support multiple
configuration mechanisms even a mixture is used throughout GNOME.

>     Rationale: this state is per-application-instance, and there is no
>     reason it has to be process-transparent in many cases. Also, the
>     per-session state does not make sense for sysadmins to fool with,
>     and there is not really much point in attaching schemas to it.
>     (Why would a sysadmin change the current positions of your
>     windows, for example? If a sysadmin might want to change a
>     setting, that's a good indication it should NOT be per-session.
>     Users should not lose important/critical settings by changing
>     session, they should only lose the state of the windows in that
>     session.)

So, should a default panel setup be attached a schema? In my view yes,
right down to the number of panels, position of the panels, number of
launchers, menu items, applets etc... It seems like the correct thing to
do so that the system administrator could assign a default panel for
users to use and have the same setup for all users on a particular
system. I think this is important if GNOME is to be used in education,
business etc... I guess the main reason is the ease of setup with
schemas [through gconftool] and support costs :)

[snip comments which I *totally* agree with]

>  G. The rollback/archiver feature should only apply to preferences, 
>     not to saved session state. For example, if we decide the
>     background is per-session (I'm not sure it should be), then 
>     it would not do rollback.

Background should be per-session, it should also be per workspace as
well [grin] - or, at least have the option to be.

>     Rationale: the intersection of rollback and sessions is just too 
>     complicated, and it doesn't make any sense anyway. Restoring 
>     the positions of your windows on Friday is not interesting.

Don't use the positioning window example, godammit! :) I'm still trying
to grasp for a scenario where rollback would be useful. I think it could
be used really great for documents ie. being able to rollback the state
of a document looking at a list of modification times.

> Comments?

We love you Havoc :P [or at least I do anyway]

				See ya,
					Glynn ;)