From kde-core-devel  Tue Nov 27 03:08:55 2001
From: Cristian Tibirna <tibirna () kde ! org>
Date: Tue, 27 Nov 2001 03:08:55 +0000
To: kde-core-devel
Subject: Fwd: session management subtlety
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=100683057609298


Despite promises, I believe nobody managed to get enough time to implement a 
simple wrapper around the SM functionalities of X in the respect of saving 
sessions on request in addition to saving at logout. This adds to what Havoc 
says below. And a (off by default) sessions browser at login would be nice to 
have too.

Nice simple work (and interesting too) for anybody who got a bit of time.

CT

----------  Forwarded Message  ----------

Subject: session management subtlety
Date: 26 Nov 2001 21:12:51 -0500
From: Havoc Pennington <hp@redhat.com>
To: xdg-list@freedesktop.org, gnome-hackers@gnome.org
Cc: Matthias Ettrich <ettrich@kde.org>, Oswald Buddenhagen 
<ob6@inf.tu-dresden.de>

Hi,

(This is a real bug in both desktops, but esoteric enough that I
expect only SM authors to know what the hell I am talking about ;-)

An interesting issue with both KDE and GNOME is that they use
SaveYourselfRequest to signal a request for a logout. Both then offer
a "save session" checkbox in the logout dialog.

Here is the problem. Say I log in at 2 pm, save my session (but don't
log out) at 3 pm, and then log out and do not save my session at 4 pm.

The way the "do not save" checkbox works in both KDE and GNOME is that
the session manager will not write its session file if you don't save
your session. However, _applications_ are still sent SaveYourself, and
still save their state.

Assuming applications store their state per-session-ID, rather than
per-SaveYourself, the result is that I would get the session file from
3pm, but the application states from 4pm. This means that e.g. I might
get the wrong number of windows open for an app. The worst case
scenario when getting the wrong number of windows is to get too few,
because the window manager gets confused and restores session state to
the next window the user opens manually. (This can result in fun stuff
like the window manager maximizing a dialog.)

This bug doesn't typically manifest when using gnome-session and GNOME
apps, or ksmserver and KDE apps, for different reasons in each case.

For KDE, AFAICT from tests with kwrite, the apps have the bug, in that
they save their state per-session-ID rather than per-SaveYourself.
That is, kwrite sets its RestartCommand to "kwrite -session
11c0a80002000100682637000000015610000" where the long string is the
session ID. However, the bug doesn't occur because ksmserver does not
allow the save at 3pm; it equates saving with logging out:

    void KSMSaveYourselfRequestProc (
        SmsConn             /* smsConn */,
        SmPointer           /* managerData */,
        int                 /* saveType */,
        Bool                /* shutdown */,
        int                 /* interactStyle */,
        Bool                fast,
        Bool                /* global */
    )
    {
        the_server->shutdown( fast );
    }

(Ignoring the "global" flag here is really a bug IMO.) Anyway, with
gnome-session, kwrite would have the bug. It's possible that even the
ksmserver/KDE-app combination has issues if you log out once and save,
then log out again and don't save - maybe for session IDs present in
both sessions you would get the app state from the second logout.


GNOME apps by default use a randomly-generated string that is
regenerated per-SaveYourself to record their session state - I don't
know if this is a deliberate response to this issue, or just dumb
luck. So e.g. "gless" sets a RestartCommand like:
 gless --sm-config-prefix /gless-y0tFYm/
This means that GNOME apps using the usual setup will always get back
the state associated with a given SaveYourself. However, there is no
real requirement in the SM spec that apps are "safe" against the
session manager in this way.


Anyhow, there are two possible fixes I can see. One is to require that
session managers always record the latest RestartCommand of any app
that has received a SaveYourself. i.e. the SM must save to disk if the
app saves to disk. The other is to require that apps save state
per-SaveYourself, not per-session ID. In either case, I think
documenting the clarified behavior would be a good idea.

Havoc

_______________________________________________
Xdg-list mailing list
Xdg-list@freedesktop.org
https://listman.redhat.com/mailman/listinfo/xdg-list