Re: gnome-session... still not saving session



>>>>> "Toshio" == Toshio Kuratomi <badger@prtr-13.ucsc.edu> writes:

Toshio> I have two apps that refuse to save state and restart:
Toshio>   [ ... ]
Toshio> I know how I want to restart both of these apps, so how can I
Toshio> edit .gnome/session manually to get these entered?  (And will
Toshio> logging out via panel afterwards overwrite my changes... so
Toshio> I'll have to make my changes from the terminal?)

You are right.  If you edit .gnome/session it will be overwritten the
next time you log out.

Applications that don't do session management and don't set the
properties wanted by smproxy are basically invisible (and lame).

The only thing to do is start them by hand in your .xinitrc.  Or fix
them!


Toshio> Second problem: panel will not start automatically and is not
Toshio> in the .gnome/session file when I log in.

Toshio> After some thought I need to know -- is the panel calling
Toshio> save-session as it is exiting?  So that it is already gone
Toshio> when the session manager writes the .gnome/session file on
Toshio> exit?  Or is this some other bug?

If the panel is connected to the session manager, then the log out
button ends up calling gnome_client_request_save -- the actual exiting
is done as a side effect of the session management "save" callback.

So I think you are seeing some other bug.  I don't know what it is.


Toshio> Final problem: I have two extra xterms that keep popping up on
Toshio> my desktop.  They are in the session file as well.  I just
Toshio> can't seem to get rid of them.  I close them and run
Toshio> save-session.  No change.  The entries are still in the
Toshio> session file.  Should I try removing those entries manually
Toshio> and seeeing what happens?  I have a feeling the session
Toshio> manager keeps a copy of the session internally and just uses
Toshio> the file to save state between invocations so that won't work
Toshio> will it..?

I've seen this too.  I believe it is a bug in smproxy.  However, I
haven't looked at gnome-session under a debugger to verify this.

The session manager does not keep state like you hypothesize.  It
keeps track of connected clients, and their respective states (during
a save a client can assume one of several states depending on the
specific transactions).

Toshio> Okay.  I lied: One more problem here.  I have an xconsole
Toshio> window open and I want it to start iconic.  I suppose the
Toshio> session manager doesn't understand that so it isn't putting a
Toshio> -iconic flag into the session file.  I try to add it manually,
Toshio> but that doesn't work... I think the session manager is
Toshio> overwriting my change to the session file.... Any cle\ue as to
Toshio> what I could do?

You have two choices:

1. Fix xconsole to be smarter about how it saves its state
2. Find a window manager that is session-aware and smart enough to
   record window state.


The session manager is a vital part of the session management
solution.  However, it is not the only part.  Clients must also be
cooperative.  Most non-Gnome clients are uncooperative.  Some will
work with smproxy (which is typically second-rate support).  Many
won't work at all.  For instance, Emacs doesn't work.

Tom



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