Re: how to store prefs/session data

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> * 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.)

I'd suggest punting this issue for now. I think it could be done long
term by providing a tool that fooled around with which backend GConf
used for which keys; i.e. we could provide this feature without
modifying apps, if GConf is used for preferences.

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

I think only the terminal class should be per-session, and all other
settings should be per-terminal-class. 

i.e. you can have an application-specific "profile" feature, where a
profile is a precanned set of per-instance settings, and the profile
definitions are a global preference.

I guess I'd say that there should be no concept of the "default"
preferences in gnome-terminal, only profiles; that all terminals
should show the same available profiles at all times (the available
profiles and their contents are global); that it should be more clear
that the prefs dialog is a profile editor, not a terminal-instance
editor; and that which profile you're editing should probably be
separated in the UI from which profile has been applied to the current
terminal.

Anyway, it's mostly a UI question. Probably g-t shouldn't have a
Preferences menu, it should have a menu of available profiles in a
radio group, and an "Edit Profiles..." menu item to edit the available
profiles. Because really it doesn't have global prefs at all.

> * 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.

There are several ways I can imagine handling the display-dependent
stuff such as background and pointer device:

 a) they are global preferences, and we have some tool which
    special-cases some set of global preferences and auto-modifies
    them for your location (location management is just this, right?)

 b) they are per-session, and you have to create a session for each 
    location, and you can't rollback these things

 c) they are global preferences, but the schema file denotes them 
    as per-machine, and GConf keeps their values in a hostname-specific 
    data repository

At the moment, and maybe I'll change my mind, I think c) is right, a)
is good enough and easy to implement, and b) is kind of broken.

> * 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?

I think a) or c) above would avoid this issue, as you say b) seems
pretty hosed.

Havoc