Filed on Launchpad:
https://bugs.launchpad.net/bugs/249265

The state of running apps is not kept when logging out even if the appropriate
box is ticked in gnome-session-properties or if the "remember current running
apps" is pressed. None of the running applications get restarted on the next
login.

Also happens in 2.24.0 on Intrepid Alpha6

And 2.24.0 on Gentoo.

*** Bug 553961 has been marked as a duplicate of this bug. ***

Happening on Intrepid Beta 1 on totally seperate PC

run /usr/bin/gnome-session-properties and manually save session, this is what
you get:
** (gnome-session-properties:27389): DEBUG: Session saving is not implemented
yet

It's something what can be expected in 2.23.x series. But for 2.24 it's a major
regression/release blocker.

Could someone change state to confirmed/critical? thank you.

In Gentoo Linux we can not give users GNOME-2.24 in good consciousness with
session saving suddenly not working at all because its implementation has
disappeared. And we don't seem to easily be able to keep gnome-session at 2.22
either due to things somewhat relying on the changes in gnome-session (though
we might have to investigate this possibility further).

Andre Klapper suggested Gnome target field is something that can be tweaked for
blocker marking, so people can see what distros are struggling with to release
a full GNOME series set.

Does anyone of the new gnome-session has suggestion/view on the use of Xsmp to
allow session to be saved and restored. The goal at
live.gnome.org/SessionManagement/NewGnomeSession says "Isolate the XSMP
code as much as possible, and make it possible to replace it with D-Bus over
time" that implies the developers want to move away from XSMP to dbus.

But further down the line, it says "XSMP clients can be matched to autostarted
apps by a number of means: .." that seems to say XSMP still place a role in
sessionning.

I have these queries:
- Is there a known dbus mechanism to response between applications and
gnome-session? That is, does applications need to set up a particular dbus
channel to talk to gnome-session?

- How much of XSMP will be retained by gnome-session going forward?

I am trying to figure out what need to be done to have session saved and
restored. But the first question I hit against the wall, where is the session
information is going to be saved to and in what form?

Can $HOME/.gnome2/session be used? That file is tightly linked to gnome-client
in libgnomeui, will that still survive going forwards?

Is there someone that I can talk to, through irc or e-mail on the above
questions?
THANKS!

I think session saving would probably need to be done by writing out desktop
files in ~/.config/autostart

Ray, I realised that session saving can write to ~/.config/autostart, but the
problem there is desktop does not provide granularity of window's geometry
(correct me if I am wrong). Hence when they are restored, the application
windows tend to stack on top of one another.

Also that does not allow applications to be restored onto workspace other than
0.

To be more precise, the desktop file specification does not allow the
specification of window geometry nor worksplace placement, so there is no mean
of restoring applications to the position required. Any comment/insight to
this?

(In reply to comment #11)
> To be more precise, the desktop file specification does not allow the
> specification of window geometry nor worksplace placement, so there is no mean
> of restoring applications to the position required. Any comment/insight to
> this?

Maybe blogs.gnome.org/metacity/2008/03/08/session-management/ has some
insight.

Regarding saving sessions in new gnome-session with desktop files, doesn't
dumping stuff to some autostart folder mean having to clean up, generate and
dump desktop files every so often, which sounds icky to me? I have in mind the
subfeature of session saving in GNOME-2.22 - save session at logout. This also
used to save the session periodically to restore it in case of a full crash,
power loss, etc.

The links made an interesting read, I noted ~/.metacity contains geometry
information about application windows. Though I have never seen it been used
long before 2.24.0 release. So according to the spec, since window manager
starts at phase 2 (or window manager phase) and assuming the phases are well
controlled, that is the apps are started /up and running before the next
(though I suspect they are spawn asyn), hence there may be time when an apps
started before metacity is able to place it. Looking at the gnome apps, class
seems pretty well specified. That may be the one to use by metacity.

I didn't realise that the sessioning stuff is that extensive. Now that GNOME
wants to move on from XSMP (even with the above blog), have anyone a complete
architectural view of the whole desktop in terms of session management?

What roles each component play:
- gnome-session
- window manager
- toolkit
- applications

2.24.1 is released with this major regression on board.
Is there is a plan to backport/re-enable session managment in g-s?
Would great to have some statement, to know when upgrading to GNOME 2.24 will
be possible.

Fryderyk: Yes, obviously, because this bug is still in open state and 2.24.1
release was on Wednesday. Everybody knows this, no need to comment this.
The bug is fixed when it's closed as FIXED.

Andre: Thank you for pointing it to me, but I'm far away from any form of a
comment in my question.

Doesn't bug #536685 describe the same issue? It also contains a patch...

Eetu, it doesn't in the complete sense. 536685 describes loading of session
file generated prior to 2.23.x release. The patch supposingly make the saved
session apps to be launched during the session start up. The bug here describes
the more complete saving current session and restoring them after a logout and
login.

*** Bug 557430 has been marked as a duplicate of this bug. ***

Same problem here on updated Ibex install with GNOME 2.24.1.

*** Bug 557243 has been marked as a duplicate of this bug. ***

*** Bug 558779 has been marked as a duplicate of this bug. ***

*** Bug 557131 has been marked as a duplicate of this bug. ***

So what's the status of that? When will 2.22 behaviour be restored? How could
that have made it into the release in the first place?

Very dissapointing to see such a major feature regression hit gnome-stable
without any kind of warning.

This feature (save session) seems like a very used feature of gnome 2.22
because it generated a lot of discussion on ubuntu
(https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/249373). I'll
consider this a regression, but I think that people must be warned about this
issue on release notes.

Will this issue be marked to 2.26 or to 2.24.x?

I have just found Matt kennan 's blog on a workaround for this feature, ere,
blogs.sun.com/mattman/entry/gnome_2_24_session_save1

May relieve some temporary pain, but certainly not all.

(In reply to comment #9)
> I think session saving would probably need to be done by writing out desktop
> files in ~/.config/autostart

Why would you want to write .desktop files? Why isn't simply continuing to
write ~/.gnome2/session sufficient as well? That file is read anyways to create
a list of resumed clients (which works fine when applying my patches in bug
536685 and buf 559450), so the only missing piece in here seems to me that
writing out the session file on session close is missing. At least the XSMP
clients should be written out to that file, maybe something different should be
done about dbus API clients.

Does the new session infrastructure even have the features of the old one? As
far as I can tell, there's no obvious way to set the order in which the
.desktop files get executed. (at least not one google's found for me yet)

(In reply to comment #29)
> Does the new session infrastructure even have the features of the old one? As
> far as I can tell, there's no obvious way to set the order in which the
> .desktop files get executed. (at least not one google's found for me yet)

You can't set the order arbitrarily, but programs are started in 5 phases, with
each phase being fully started before the next one begins. See
live.gnome.org/SessionManagement/GnomeSession

(In reply to comment #28)
> (In reply to comment #9)
> > I think session saving would probably need to be done by writing out desktop
> > files in ~/.config/autostart
> 
> Why would you want to write .desktop files? Why isn't simply continuing to
> write ~/.gnome2/session sufficient as well? That file is read anyways to create
> a list of resumed clients (which works fine when applying my patches in bug
> 536685 and buf 559450), so the only missing piece in here seems to me that
> writing out the session file on session close is missing. At least the XSMP
> clients should be written out to that file, maybe something different should be
> done about dbus API clients.
> 

One aspect of the BIGGER picture in gnome-session change is Project Ridley
which is to remove the use of libgnome/libgnomeui. In libgnomeui there provides
the toolkit API to access to ~/.gnome2/session. So whether we will be able to
use this file will depend on the new sessioning whether or not to adhere to the
the similar syntax and semantics. What I meant is when GNOME applications do
not linked against libgnomeui, that functionalities will disappear.

There is no clear indication as I can see from
live.gnome.org/SessionManagement/GnomeSession
May be someone who work on session like to fill in the BIG picture.

Meanwhile, I must say Danny, you are doing some good works to fill the gap :)

(In reply to comment #31)
> One aspect of the BIGGER picture in gnome-session change is Project Ridley
> which is to remove the use of libgnome/libgnomeui. In libgnomeui there provides
> the toolkit API to access to ~/.gnome2/session. So whether we will be able to
> use this file will depend on the new sessioning whether or not to adhere to the
> the similar syntax and semantics. What I meant is when GNOME applications do
> not linked against libgnomeui, that functionalities will disappear.

Well, not exactly. I know that old gnome-session used gnome_* functions to read
and write that file, but new gnome-session uses g_key_file_* functions to read
it; thus my assumption was that GKeyFile can also be used to write it. But
maybe I am wrong there.

> Meanwhile, I must say Danny, you are doing some good works to fill the gap :)

Thanks :)

(In reply to comment #30)
> (In reply to comment #29)
> > Does the new session infrastructure even have the features of the old one? As
> > far as I can tell, there's no obvious way to set the order in which the
> > .desktop files get executed. (at least not one google's found for me yet)
> 
> You can't set the order arbitrarily, but programs are started in 5 phases, with
> each phase being fully started before the next one begins. See
> live.gnome.org/SessionManagement/GnomeSession
> 

So it seems like the common use case about 90% of the time is that a user wants
a particular program running whenever they're logged in, in the background.

Is there any information as to how a user could squeeze a program that doesn't
exit until finished into these phases, say, the initialization phase? Is there
a way to tell it not to wait for a program to exit, or respond, that it's just
an application that's not aware of this new infrastructure?

It seems like there's alot of MUST's in this system that apply to applications
that are not a part of gnome, or even legacy applications that will never be
updated. There needs to be some way to squeeze them into this process.

(In reply to comment #33)
> So it seems like the common use case about 90% of the time is that a user wants
> a particular program running whenever they're logged in, in the background.

It sounds that in this case, people should just use the autostart specification
(use the session capplet to add programs that should be started on login)