Re: how to store prefs/session data

[Maciej Stachowiak <mjs noisehavoc org>]

On 10Oct2001 01:21AM (-0400), 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.

This sounds like a good first cut at a design.

Here are some questions to poke at a few of the design's assumptions:

* If a user wanted one setup where Nautilus uses a new window for each
directory and has the toolbar and location bar off, and another where
it has the default settings (perhaps because of differences in
available screen size or pointer device, I dunno) how would they do
that under your proposal? (Note: this is neither a session setting nor one
that is managed by the control center.)

* How should settings that an app currently lets you set globally _or_
per-instance, like some of the terminal settings be handled?

* Your design implies that display size is stored only per session and
not globally. I'm assuming you would handle pointer device settings,
color depth, etc, the same way. But if the control center "location
management" feature must therefore not apply to these settings, it
doesn't really work for purposes of location management, since these
are some of the primary things you may want to be different between
locations.

* Let's say display size and color depth are per-session. Does that
mean that gtk theme, background color, window manager theme and all
font and color settings must be per-session only (since it's clear
that you might want all these things different between color and
grayscale, 8-bit color and 24-bit color, and different screen
resolution)? Does that imply that changing themes and fonts and colors
will not be remembered next time you log in unless you save the
session? Is that acceptable if we leave not saving the session as teh
default?

 - Maciej

 
>  A. Only settings related to window sizes/positions, application 
>     _instance_ state (e.g. currently open document), 
>     and display size, should be stored per-session. 
> 
>     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.
> 
>  B. These settings should NOT be stored globally, at all. i.e. for a
>     given setting, it is either global or per-session. This implies
>     for example that when using bonobo-config, you would have 
>     one property bag for global settings, and one for per-session, 
>     and you would not ever interchange those property bags.
> 
>     Rationale: it just doesn't make sense to mix the session 
>     state with user preferences. This would seem obvious but
>     some apps seem to miss it. You CANNOT implement saving 
>     the session by pushing a different config prefix onto 
>     your standard prefs-saving code.
> 
>  C. There is nothing wrong with storing per-session state in flat 
>     files or whatever rather than gconf.
> 
>     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.)
> 
>  D. However it may be useful to store session info in gconf, 
>     for example for apps made up of multiple processes, or 
>     whatever. If you save session data in gconf, it's encouraged to
>     do so in a directory called 
>      /apps/appname/sessions/escaped_session_id
>     where escaped_session_id is a session ID converted to 
>     a valid GConf key. Then DiscardCommand should be set 
>     to "gconftool --recursive-delete
>     /apps/appname/sessions/escaped_session_id"
> 
>     I need to add a key-escaper function and --recursive-delete
>     to GConf, I'll do that.
> 
>     Rationale: the standard "sessions" subdir containing session IDs
>     will keep things simple and help people browsing the GConf 
>     database quickly understand what that data is used for. 
>     Also, storing everything under one dir makes the DiscardCommand 
>     easy.
> 
>  E. Preferences should be stored in the usual place in GConf, 
>     under /apps/appname, and be global.
> 
>  F. For per-session state used by multiple apps, I suggest we
>     extend the SM protocol to have a session ID for the entire 
>     session, in addition to one for each app instance. Then, 
>     we add a function to gnome-client to get this ID.
> 
>     For the desktop background, assuming that is a per-session
>     setting, we would then save at the key:
>       /desktop/gnome/sessions/escaped_global_session_id/background
> 
>     Rationale: seems like the obvious way to address this issue, 
>     and should not be difficult to implement.
> 
>  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.
> 
>     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.
> 
> So, this involves two API additions (gconf_escape_key() and
> gnome_client_get_global_session_id()), plus one gconftool feature
> (--recursive-delete).
> 
> Comments?
> 
> Havoc
> 
> Earlier mail - 
> 
> Things users might want to do
> ===
>  
>  (pure speculation)
> 
>  - have state specific to a display (monitor/mouse/keyboard
>    combination, i.e. typically a single physical computer)
>  - explicitly create a set of apps that normally launch when they log
>    in
>  - have these apps they saved come up at a specific size/position 
>  - be able to log out, and log in again, automatically/implicitly
>    restoring the apps they had open on logout
>  - have apps restore their size/position each time they are launched,
>    a la MacOS (different from restoring size/pos of a particular
>    instance, as with session management)
>  - temporarily log out, let someone else log in, then go back 
>    to their session (as with Windows XP)
> 
> A sampling of preferences, settings, state, whatever
> ===
> 
> panel - 
>   - animation speed for hiding
>   - tile style
>   - size of icons in menus
>   - menu contents
>   - keybindings
>  
> properties of specific panels - 
>   - panel type
>   - size
>  
> nautilus - 
>   - icon/list view
>   - fonts to use 
>   - open files in new window vs same window
>   - window contents (toolbar, sidebar)
>   - manage the desktop
>   - single vs. double click
>   - home URL
>   - search engine URL
>   - news panels
> 
> gedit - 
>   - show statusbar
>   - toolbar style
>   - font, colors
>   - print setup (word wrap, banner, line numbers, paper size)
> 
> generic properties of any app's current state - 
>   - number and type of open windows
>   - window size/position 
>   - window desktop
>   - documents opened in each window
> 
> desktop-wide preferences/state - 
>   - theme
>   - background/wallpaper
>   - default font
>   - mouse acceleration
>   - key repeat rate
>   - screensaver
>   - favorites/bookmarks
>   - recently-used documents
> 
> Current infrastructure
> ===
> 
> Session management: we have a unique identifier for each application
> instance, which allows apps to save per-instance state. Also, a
> mechanism for window managers to save application window state.  Could
> trivially add an ID for a global named session, allowing us to save
> per-session state. (But importantly, in the current codebase, you
> can't store per-session state; only
> per-instance-of-an-app-that-is-in-a-session state. A subtle
> distinction, but it means that currently a global setting like
> background color can't be per-session. We'd need a trivial SM protocol
> extension for this.)
> 
> GConf: Stores preferences in a global process-transparent way.
> 
> gnome_config_*: Stores simple text files.
> 
> bonobo-config: stores key-value pairs in a variety of locations
> including GConf or text files.
> 
> Archiver: stores XML files with date-stamped dumps of current state,
> and can stuff the snapshot from any date back into the config
> system. (right?)
> 
> Questions
> ===
> 
> What do users really want to do?
> 
> What should the UI for doing that look like?
> 
> How do we reliably and consistently implement it across the desktop?
> 
> How do we do this while still providing the admin benefits of GConf?
> 
> Can we divide the list of sample prefs/state given above into some
> sort of categories? Do we treat some of them differently?
> 
> Did we answer any of the above questions with something overengineered
> or overcomplicated?
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> gnome-2-0-list mailing list
> gnome-2-0-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-2-0-list