Re: location management vs. session management



Heya,

Okay...I agree that we must go with the session manager for some
things....but after that I'm open to suggestions...

Seemingly the location manager is really just a GUI that uses the 
archiver backend. Since we have a chooser GUI in gdm, does it make
sense to drop the location manager GUI and have the archiver stuff
[with associated rollbacks, rollforwards] being per-session, where
gnome-session defines the session ie. through the sm-clientID? 

But then I guess we need some sort of GUI for the rollback stuff...
Man, this sucks ;) 

Another thing, when you want to base a new session of a pre-existing
one, you need to propagate the save_yourself call to the apps 
[which is done already] but that save_yourself must propagate to the
apps config...and that means interaction between bonobo-conf and SM.

Have fun :)

/me runs away to deepest, darkest Peru

				See ya,
					Glynn ;)

Havoc Pennington wrote:
> 
> Multi-session only provides feature 1, right, not the other two.
> 
> Let me toss out this idea: if there are no advantages to the archiver
> for 1, I think we should use the multi-session for that. Because the
> SM spec also allows saving window sizes, positions, etc. in addition
> to app config (and this has to be done by the window manager, we can't
> store it in apps).  Also, the SM spec is cross-desktop and
> cross-app. e.g. I'm trying to get it supported in Mozilla, because
> Sawfish's incorrect placement of Mozilla drives me crazy. ;-)
> 
> Of course a specific app, such as a control panel, could use
> bonobo-conf to store the per-session data, etc.
> 
> If that sounds OK, the remaining question would be, how do features 2
> and 3 work in a multi-session world. That is, is the undo list
> per-session?
> 
> I guess 3 can't have a relation to multisession, since it's for system
> settings and sessions are per-user.
> 
> I really think the resulting UI will be scary if we have both
> multi-session and the separate location management concept, unless we
> can think of some logical interaction, so I think this is a pretty
> important issue to resolve. How do you think we should approach it?
> 
> Havoc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]