Re: [Vlad Harchev <hvv hippo ru>] problem with session management ingnome-1.4beta1

[Vlad Harchev <hvv hippo ru>]

On Mon, 5 Mar 2001, Glynn Foster wrote:

> >  OK, then my memory is corrupted (I'm not 100% sure that gnp was
> > restarting, but I have an impression that it did) and gnotepad wasn't
> > restarting for me. I'm sorry for confusion then.
> 
> Okay...maybe it's me who's confused...I didn't have either on my system 
> and assumed gnotepad is the same as gnp?....In any case, it's a fault of
> the original application and their implementation of the save_yourself
> command [see libgnomeui/gnome-client.h]

 Yes, gnp is gnotepad. I was able to test gnp and old gnome - and yes, gnp
also wasn't loaded when session with it was started. 
 
> >  Hmm, just tried again. I'm getting impression that in order to restart named
> > session, I have to use gnome-session with some argument from commandline,
> > since when I select another default session in gnomecc (having "save session
> > on logout" unchecked), logout and login, and get the session I just left
> > (since it's apprently was saved).
> > 
> >  What I (and probably all users) expected is when I logout (just after
> > changing a name of default session via gnomecc), the session I quit gets saved
> > under previous "default session name" (or the one I was started), so that
> > when I login next time, I get another session (a state that was saved in
> > recently-became-new "default session"); in reality (behaviour of gnome-1.4b1)
> > the session I quit seems to get saved under new "default session name" - i.e.
> > when I login I'll get the session with state I just quit. This means
> > that without involving gnome-session from commandline user won't see ANY
> > visible trace of named session support.
> >  Also it seems that "save session" options gets useless (since gnome-session
> > ignores it and save session unconditionally). (I.e. having that option
> > unchecked and "don't ask to confirm saving session" checked and without
> > changing name of "default session", session still gets saved.
> > 
> 
> Okay...the way it *should* work is the following -
> 
> gnomecc get the list of saved sessions from the ~/.gnome/session file and
> highlights the current session you have loaded. It then gives you an
> opportunity of being able to edit the name of the current session, adding
> new sessions and editing existing sessions. This only affects
> ~/.gnome/session file. When you highlight a session, it changes the name
> of the session that gnome-session holds in memory and also changes the
> ~/.gnome/session-options file.
> 
> So in order to change to a different session, you must highlight the
> session you want [which most importantly changes the CurrentSession
> key/value pair in ~/.gnome/session-options], make sure that the autosave
> check box is off and then logout. Upon logging back in again, you *should*
> get the new session you previously highlighted with associating
> applications.
> 
> But what is currently happening is that gnome-session is saving on logout
> [and seems to have a habit of saving at other times too] regardless of
> what you do. This is a bug which I've been trying to fix [although not
> very successfully].
 
 Thanks for an explanation - the scheme you described sounds like exactly
what's needed. I hope it won't be too hard to fix gsm.

> The --choose-session=ARG is really designed for remote displays. Actually
> it would be nice to be able to select a session to load from gdm, but
> that's not a beta issue ;)

 We can hack script that starts gnome-session to start 'gdialog' (kinda
'xmessage' program for GUI interaction from shell scripts) popping a GtkCList
of saved sessions (if there are more than one session stored), and use the
user choice as ARG in gnome-session --choose-session=ARG. That's only 10 lines
of shell code, that will bring us that flexibility, without the need for
hacking any desktop manager. What do you think about this?

> 
> > Multisession support in theory is very cool feature to me, and all I
> > have to dream now is reality matching that theory :)
> 
> And a misery to code :/ [or maybe that's just gsm...]

 Good luck fixing all this :)
 
> 
> 			See ya,
> 				Glynn ;)
> 

 Best regards,
  -Vlad