Re: Multi-sessioning for GNOME [revisited]

[Colm Smyth <Colm Smyth ireland sun com>]

>From: Glynn Foster <glynn foster Sun COM>
> ...
>Havoc Pennington wrote:
>>
>>For GConf, the basic idea we had, which I guess is in the thread Glynn
>>mentioned, is that we have a way for apps to install a hint "this
>>setting is per-display" or "this setting is per-session" or
>>whatever. Then, GConf would have a per-session storage backend that
>>gets the per-session settings. That's nice and simple, and works
>>properly.
>
>Yes...I all for this certainly...Is there any huge (you can't touch that) 
>reason why this can't be implemented for GNOME1.4. If we can get this 
>sort of stuff into GConf the sooner the better. Sure it might be a case 
>of only getting pretty much skeletal code, but at least it would be a
>start..

Adding hints to configuration variables is in my view a bad idea:

- requires programming effort in every application
- creates configuration data that is forked along fixed meta-variables
  (such as display)
- complicates back-end storage

I believe we can achieve the same effects by having a partition map
in GConf that routes data to/from specific GConf databases and
with a configuration path that combines these GConf databases in
the most useful way. To do this, each GConf database contains meta-data
in the form of a description of the GConf configuration hierarchies it contains.

An example:

Let's say that the binding between a MIME content-type and an
application or BONOBO component that supports view/editing that
content-type is stored in a GConf key hierarchy "/gnome/desktop/mime".

If a user wants to make the MIME bindings specific to the display,
they could create one GConf database for a local display and
another that applies to all remote displays (maybe because an
image-editing app is powerful but redraws slowly, while another
app offers few editing features but redraws efficiently).

The GConf partition map is my concept for a way to combine
multiple GConf databases dynamically at run-time, based
on data available from the environment. It would allow
GNOME to combine for example:

- a default desktop configuration that comes with GNOME 
- a shared configuration made available via NFS for use
  by all programmers in a team
- the user's core configuration
- the user's display-specific configuration
- the user's architecture-specific configuration (choosing
  say applications according to the chip-type (RISC,
  Intel-compatible, ...))
- and so on...

The main advantage of separating configuration data into
multiple GConf databases is that they can be combined
in arbitrary ways, and this combination can be entirely
determined by data which is also stored in GConf.

By separating different sub-configurations into different
GConf partitions, apps don't have to maintain 'hints'
for individual configuration keys and the ways of partitioning
and combining different parts of each user's desktop's total
configuration are infinite.

I emphasise again though, a well-designed GUI is critical to make a
lot of this flexibility easy to use. I have done some work
on a UI design for a GConf editor, but it's still not easy enough.
I want to be able to select a configuration tree (such as
/gnome/desktop/mime) and to drag and drop it to another configuration
partition. If I am an administrator, I want to be able to do the
same for a shared GConf configuration database.

Colm.

>Alan Cox wrote:
>>
>>You add markup to the variable to indicate if its global or session oriented.
>>Thats also about 20 lines of code to fix for gnome 1.4, then tweak the apps
>>as needed
>
>Yes...it's the 'tweak the apps' bit that I don't like....especially when it is
>likely that we'll have to 're-tweak the apps' a few weeks/months down the line.
>
>Havoc Pennington wrote:
>>
>>Yes, but I think it's stupid to make future upgrades to the right way
>>much more painful, when GNOME 2.0 is in the pretty near future. We
>>shouldn't introduce some feature that we're going to break and change
>>with confusing results only a few months later.
>
>Well as you said yourself, 'I think gnome-session already more or less supports 
>multiple sessions'......I'm all for getting this stuff in GConf as early as 
>we can, if that is possible.....but I *do* think that the code change for the 
>idea that I suggested would be relatively small and certainly would have little
>impact on anything *but* gnome-session, and hence make a future transition to 
>GConf quite easy.
>
>Havoc Pennington wrote:
>>
>>I will get bugs in the Red Hat bug tracker about
>>how the session stuff doesn't make any sense, and I'll be embarassed
>>to close them with "supposed to work that way."
>
>Hmmm...I can say that about a *lot* of apps and features....That should
>have nothing to do with the argument.
>
>>Well, they can apply a patch to their copy. But I don't think we
>>should introduce this kind of thing in 1.4 only to break it again in
>>2.0, especially since it won't even work properly in 1.4. Even if we
>>do, we should still encourage the Sun team to fix it for 2.0.
>
>I can see what you are saying alright...but applying a patch isn't the 
>right thing...I can see two options -
>	1) Getting this into GConf now [even if it's only skeletal, it
>	   will still provide a base to start from]
>	2) Coming up with a temporary solution until we work out a solution for 
>	   GConf and GNOME2.0
>
>>Look, there are these guys at Sun who have session management working
>>in CDE. We should encourage them to get it working really well in
>>GNOME: make sure the window manager saves app positions, make sure
>>apps actually save things such as open documents and cursor positions,
>>and so on. It's not a huge job to get this right, they are willing to
>>do it, let's encourage them to do it right.
>
>Yes, we want to see multi-session support for GNOME...not only because
>the CDE customers will complain if it's not there ;), but also because
>it will benefit the community and GNOME users worldwide....
>gnome-session, as I see it, is quite flaky at the moment....stuff 
>not getting restored on login (but might be because apps are not 
>providing the correcting information when the session-save call 
>is made)......
>
>Now either way we go with above, I think that multi-session support 
>should be included for GNOME1.4 because lots of users would find it a useful 
>feature and we would be able to review the existing session code, especially
>if we start moving over to GConf right away...
>
>		Anyway, all opinions gratefully received,
>			Glynn ;)
>-- 
>Glynn Foster				Email: glynn foster ireland sun com
>CDE Group				Tel:   +353 - 1 - 8199782
>Sun Microsystems Ireland Ltd.           Generation dot-COM        i||c Gman
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>

--
Colm Smyth - Sun Microsystems, Ireland - Desktop S/W Engineering
Sun Xtn: 19166    Phone: 353-1-819-9166   Fax: 353-1-819-9200