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 http://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 http://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,
http://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 http://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 http://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
> http://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)

Except that there's then no way of ensuring that any one program starts before another. In order to participate in that discussion, applications have to support gnome's new way of doing things, or face second-class status to the session manager.

This is not a change from gnome-session 2.22; if you wanted to use the "priority" mechanism to control startup order in 2.22, you needed to use XSMP to register with the session manager.

In fact, 2.24 makes your life *easier*, in that there are now three ways for early-launched apps to communicate with the SM: XSMP, D-Bus, or (for programs launched in the Initialize phase), just exiting with status 0.

(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.
> 

Count me as one of the 10% then. I have an arrangement of terminals that I want to keep across sessions. In 2.22 (and as long back as I can remember, I used gnome from before 1.0) this just works. Having the SM just start gnome-terminal only gives me one terminal, in a random location, not 4 in the place I left them. This is only one example, I also like to keep epiphany and evolution open on desktops 7 and 8, when I log back in with the old SM, they appear on the desktop I left them. Please fix properly! This has *always* worked in the past, and in all the other desktop environment this still works.

If any of the gnome devs care to mentor me on this, I'd even implement this myself.

(In reply to comment #36)
> This is not a change from gnome-session 2.22; if you wanted to use the
> "priority" mechanism to control startup order in 2.22, you needed to use XSMP
> to register with the session manager.

Are you saying gnome-session will always maintain XSMP support?
How about toolkit support for the client? Is that going to be moved from libgnomeui to gtk+?

> 
> In fact, 2.24 makes your life *easier*, in that there are now three ways for
> early-launched apps to communicate with the SM: XSMP, D-Bus, or (for programs
> launched in the Initialize phase), just exiting with status 0.
> 

Can you elaborate on this? How are the apps be orders in relation to XSMP and D-Bus?

(In reply to comment #38)
> Are you saying gnome-session will always maintain XSMP support?

I don't know what the plan is.

> How about toolkit support for the client? Is that going to be moved from
> libgnomeui to gtk+?

Hopefully. See bug 79285.

> > In fact, 2.24 makes your life *easier*, in that there are now three ways for
> > early-launched apps to communicate with the SM: XSMP, D-Bus, or (for programs
> > launched in the Initialize phase), just exiting with status 0.
> 
> Can you elaborate on this? How are the apps be orders in relation to XSMP and
> D-Bus?

The ordering is determined by the .desktop file keys, as mentioned before. XSMP and D-Bus are just two different ways for the app to communicate with gnome-session after it has been started.

I'm another of those people who wants a specific size and layout of gnome-terminals -- I use 2 windows, each with 4 tabs, at specific locations and sizes. Just want you to know there's more than one of us.

I'm another one of those people that found this feature exceedingly useful. So useful that I postponed upgrading most of my machines when I found out about this bug.

I use(d) this feature extensively at work for example (or for school work at home) so that I can come back the next day and have all my windows open and ready for me to dive right back in to work. Multiple terminals, Gedit with multiple files open and Firefox with multiple tabs, all as I left them the day before. It greatly helped/helps my workflow. 

The fallout from this bug is even worse.  On my dual-head system I created two extra panels that mirror the default panels and put them on monitor 2.  Now when I logout and log back in, I end up with the 4 panels on monitor 1 stacked over/under each other.

gnome-session-2.24.1-3.fc10.i386
gnome-panel-2.24.1-3.fc10.i386

Or am I mistaken and this is actually a different bug?  Can others confirm this?  It may even be possible to replicate on a single-head system with non-default panels.

(In reply to comment #42)
> Or am I mistaken and this is actually a different bug?  Can others confirm
> this?

This is a different bug, probably a panel bug.

I've got to install Xubuntu to retrieve the function. I hope the bug will soon be corrected.

This is a major regression.  How did this slip in?

Here's yet another distro-specific bug for Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=471980

I would also echo the comments above (comment #37 comment #40 comment #41), I always used session management as a *complete* management for the entire set of apps that supported it which included all of my regular apps: gnome-terminal, galeon etc. (didn't use any non-GNOME apps like Firefox etc.).  I think the proportion of users using it this way is more than 10%.

It all worked fine up until this release of GNOME (everything got saved and restored).  In fact it was one of the features in GNOME that got Mac users (for example) envious when i showed them.  It's very disappointing that all of session saving on logout completely disappeared in one hit. :-(

This problem was first reported on Sep 15 it's now Dec 17 and still no fix.  I find this feature very useful and because of this serious regression I have postponed upgrading my systems to F10.  What's the hold up? I'm running version gnome-session-2.24.2-1.fc10.x86_64.

Paolo, Manu: Whining does not really help in getting things fixed.
"What's the hold up?" Write the code for it and attach it here.

Andre, this code is present in 2.22, last usable gnome-session release.

Yeah. And the codebase for 2.24 has changed a lot, so the 2.22 code has to be adapted/changed a bit. Just do it, the code is available. *shrug*

No changes are needed to make gnome-session 2.22.3 work with GNOME 2.24.
Only change needed to 2.24 codebase is downgrade of gnome-panel to 2.22.2 version (because it uses new super duper shiny DBUS interface). Minor "package level" intervention requires vino, but only for vendors with strict package dependencies.

So I've installed 2.24 with gnome-panel 2.22.2 and gnome-session-2.22.3 and it seems to work well here. Now, I can enjoy working session management again.

Nobody is whining here dear Andre. People are just angry and disappointed that GNOME policy allows to release not finished programs to end users without saying a word about regressions. This is not serious. gnome-session 2.24.x still got
2.23.x quality and releasing it was a mistake.

Or you can use gnome-session-2.22 + gnome-panel 2.24 with this patch:
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/distfiles/gnome-panel-2.24.2-logout+po.tar.bz2 

It is an enhanced version from the one I originally posted in bug #561112 and is forward compatible with gnome-session-2.24 so you get to choose which gnome-session you want to use.

Yes it's hackish but gnome-session-2.24 is a no go in gentoo until this situation is fixed.

This is a little bit alarming.  These *shrug*s and the like are not giving me the feeling of urgency that I normally associate with finding a really big regression in a stable point release.

I'm sympathetic to a degree, because I work on other projects often criticised for their bugginess.  But even I can't quite imagine letting such a big regression go unnoticed, to the extent that it not only isn't mentioned in the release notes, but isn't awarded an OH MY GOD DID WE REALLY RELEASE THAT when the first reports file in.

I would like to think that this happened because an enthusiastic young developer built up a brilliant new design, got half-way through implementing it, then saw it released while unready at an unexpected point -- and the consequent worry is that the more we hound developers on this, the more we put them off developing at all.  That would be a terrible pity, and I think there is an appreciation here all around that a modern replacement for the XSMP could be a great thing.  The error seems to be a management one, rather than a development one.

Maybe it's just a question of expectation and taste.  Like a previous poster here, I used to enjoy the fact that session management was one of the few things Linux did unambiguously better than other operating systems.  Now it doesn't, at least for Gnome users -- and it was a shock to me to find that other developers never actually saw it as important in the way that I did.  My world is not exactly torn apart, but it may have been slightly tweaked in a small corner somewhere.  Gosh, maybe my view of that corner of the world was wrong all along.

In the mean time, I'm running gnome-session 2.22 and gnome-panel 2.22 quite happily with the rest of Gnome 2.24 on several machines.


Chris

This bug was set to "blocker" on October 9th, before 2.24.1 was released. It's assigned to Vincent Untz, but I haven't seen any comment from him suggesting this is going to be fixed. If it's not going to be fixed, set it to WONTFIX and be done with it.

Vincent: Will this bug be fixed? Even if it means completely rolling back the session code to 2.22, as distributions have been doing, it's critical that it happen if people are to retain confidence in this product's release philosophy.

When will it happen? Will we see a 2.24.x release with this corrected? Or will people have to wait until 2.26.x, or later?

Dropping backwards compatibility in a 2.x release for something this significant sends the wrong message about the gnome project's priorities.

Somebody fix this shit, the startup is already slow as hell and metacity seems to be complaining delaying the startup even more.

(In reply to comment #40)
> I'm another of those people who wants a specific size and layout of
> gnome-terminals -- I use 2 windows, each with 4 tabs, at specific locations and
> sizes. Just want you to know there's more than one of us.

I did the same.  Since only Gnome apps seemed to work I just had the Gnome terminal with 3 tabs as my default start up configuration.

I also filed a bug (not sure if it was with Sun or if I filed it here in bugzilla) that when you upgrade from an older version of Gnome to a newer one your desktop can be hosed.  An example of this is going from Solaris 10 to Solaris 11.  You must delete the saved information before starting the newer version of Gnome.  In my case it would hang the Gnome session and it had to be killed via an ssh from another system, since the console was then unusable.  I hope any fix addresses such an issue.  If a previous version can't be upgraded to the newer format, then wipe it out and tell the user they must configure their saved session info again.

Mike

Ok, taking this hot potato :-)

Great Lucas! I'll buy you a beer at FOSDEM if you fix this beforehand :-)

Lucas, just wondering if you've made any progress with that "hot potato" ?

So, what is the current state of this problem?

The current state is that Lucas is working on this, and also that 2.24.x will not see any *releases* anymore ("releases" is not "code commits").
Hence retargetting to 2.26.

OK, thanks for the info. 

gnome-session-xsession-2.24.3-1.fc10.i386
gnome-session-2.24.3-1.fc10.i386

imsettings information
==========================
Is DBus enabled: yes
Is imsettings enabled: yes
Is GTK+ supported: yes
Is Qt supported: no
DESKTOP_SESSION: gnome
DISABLE_IMSETTINGS: 
IMSETTINGS_DISABLE_DESKTOP_CHECK: 
DBUS_SESSION_BUS_ADDRESS: unix:abstract=/tmp/dbus-rubs96haxV,guid=aca7c67d0968eb430a048db549897706
GTK_IM_MODULE: 
QT_IM_MODULE: scim-bridge
XMODIFIERS: @im=imsettings
IMSETTINGS_MODULE: SCIM

Started SCIM
視窗總管警告：無法讀入已儲存的作業階段檔案 /home/don/.config/metacity/sessions/108bfa61269d01ce7f123374567370875500000028430022.ms：開啟檔案‘/home/don/.config/metacity/sessions/108bfa61269d01ce7f123374567370875500000028430022.ms’失敗：沒有此一檔案或目錄
Warning:          Key <OUTP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KITG> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIDN> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <KIUP> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          Key <RO> not found in evdev+aliases(qwerty) keycodes
                  Symbols ignored
Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <I149> (keycode 149)
Warning:          No symbols defined for <I154> (keycode 154)
Warning:          No symbols defined for <I161> (keycode 161)
Warning:          No symbols defined for <I168> (keycode 168)
Warning:          No symbols defined for <I178> (keycode 178)
Warning:          No symbols defined for <I183> (keycode 183)
Warning:          No symbols defined for <I184> (keycode 184)
Warning:          No symbols defined for <FK13> (keycode 191)
Warning:          No symbols defined for <FK14> (keycode 192)
Warning:          No symbols defined for <FK15> (keycode 193)
Warning:          No symbols defined for <FK16> (keycode 194)
Warning:          No symbols defined for <FK17> (keycode 195)
Warning:          No symbols defined for <FK18> (keycode 196)
Warning:          No symbols defined for <FK19> (keycode 197)
Warning:          No symbols defined for <FK20> (keycode 198)
Warning:          No symbols defined for <FK21> (keycode 199)
Warning:          No symbols defined for <FK22> (keycode 200)
Warning:          No symbols defined for <FK23> (keycode 201)
Warning:          No symbols defined for <FK24> (keycode 202)
Warning:          No symbols defined for <I217> (keycode 217)
Warning:          No symbols defined for <I219> (keycode 219)
Warning:          No symbols defined for <I221> (keycode 221)
Warning:          No symbols defined for <I222> (keycode 222)
Warning:          No symbols defined for <I224> (keycode 224)
Warning:          No symbols defined for <I226> (keycode 226)
Warning:          No symbols defined for <I228> (keycode 228)
Warning:          No symbols defined for <I230> (keycode 230)
Warning:          No symbols defined for <I248> (keycode 248)
Warning:          No symbols defined for <I249> (keycode 249)
Warning:          No symbols defined for <I250> (keycode 250)
Warning:          No symbols defined for <I251> (keycode 251)
Warning:          No symbols defined for <I252> (keycode 252)
Warning:          No symbols defined for <I253> (keycode 253)

** (gnome-settings-daemon:3102): WARNING **: NumLock remembering disabled because hostname is set to "localhost"
Acceleration key: disabled
*** Exiting...
XSETTINGS manager support is explicitly disabled.

** (gsynaptics-init:3133): WARNING **: Using synclient
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
N: main.c: Called SUID root and real-time and/or high-priority scheduling was requested in the configuration. However, we lack the necessary privileges:
N: main.c: We are not in group 'pulse-rt', PolicyKit refuse to grant us the requested privileges and we have no increase RLIMIT_NICE/RLIMIT_RTPRIO resource limits.
N: main.c: For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.

** (nautilus:3123): WARNING **: Unable to add monitor: 不支援
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
Failed to load x11 FrontEnd module.
Loading socket Config module ...
Creating backend ...
Loading x11 FrontEnd module ...
Failed to load x11 FrontEnd module.

(gnome-terminal:3294): Vte-WARNING **: 未指定控制字元序列‘device-control-string’的處理方式。
已載入個人辭典擴充元件。
已載入 Gucharmap 擴充元件。
已載入更新通知擴充元件。
PowerWord data parsing plug-in loaded.
Dict.cn plug-in loaded.
Spelling plugin loaded.
Wiki data parsing plug-in loaded.
XDXF data parsing plug-in loaded.
已載入 Man 擴充元件。
已載入 Espeak 擴充元件。
QQWry plug-in loaded.
HTML data parsing plug-in loaded.
WordNet data parsing plug-in loaded.
WordNet dict rendering plug-in loaded.
bookname: Soothill-Hodous Dictionary of Chinese Buddhist Terms , wordcount 16687
bookname: XDICT漢英辭典 , wordcount 158152
bookname: 漢德辭典 , wordcount 64097
bookname: 朗道漢英字典5.0 , wordcount 395426
bookname: 佛學大辭典 , wordcount 30842
bookname: XDICT英漢辭典 , wordcount 177824
bookname: 佛光大辭典 , wordcount 22521
bookname: 朗道英漢字典5.0 , wordcount 423246
** (evolution:3460): DEBUG: mailto URL command: evolution --component=mail %s
** (evolution:3460): DEBUG: mailto URL program: evolution
libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files

doncot: so what? not helpful at all.

Are there any updates on the status of this bug?  When do we expect to see a fix?

Please stop asking about the status. The status is visible in bugzilla and you can subscribe to the bug to receive further updates. Sending "daddy, are we there yet" emails to everyone is plain rude.

If you want it fixed by tomorrow feel free to use your time and work on a patch instead of pushing other people to do it.

I am subscribed to this bug and the only status/updates I see are from people who add their email addresses.  If there is another bug where status exists then point me to that bug.  I work with bugs everyday for the company I work for.  My management requires that I update my bugs on an almost daily basis when they are tagged as urgent/blocker as this one is.  So based on what I am required to do I expected more activity regarding this bug.  I apologize if asking for status is improper.

(In reply to comment #67)
> I am subscribed to this bug and the only status/updates I see are from people
> who add their email addresses.  If there is another bug where status exists
> then point me to that bug.

There's no other bug. Lucas has a patch nearly ready, AFAIK.

(fwiw, I don't want to blame anyone since you can't know about this, but this is the kind of bug where each time someone asks the status, it kills my motivation to work on the bug)

Ok, here we go. I just commited in trunk the initial support for session saving. It will probably have some issues but I thought it would be better to get some testing before the 2.25.92 release.

Some notes:
- Some GNOME apps removed session client code as part of the getting-rid-of-libgnome[ui] tasks. Consequently, those apps will not to be "seen" by the session saving and restoring;
- No session saving support for D-Bus session clients yet. I'll probably have to make some additions to the protocol before implementing this. The D-Bus session management protocol is not considered official yet and most of the apps out there use XSMP for session management anyway. Hence, no big deal here;

How you can help:
- Get latest gnome-session and try it
- Report issues as comments here

Hi Lucas,

Did you by any chance test this to make sure it doesn't break GDM?

Will be XSMP clients still supported? If no, are there any plans for the XSMP proxy for the new D-Bus session management? (Actually, XSS proxy for the D-Bus screensaver management would be useful as well and may share part of the code.)

Hi,

I tested svn rev 5298. 

Running apps are restarted (so far tested with gnome-terminal, epiphany, evolution), but:

- apps are not restored to correct desktop (evolution, epiphany), this was the case in 2.22 (which I'll use as a reference implementation)
- apps are not restored to their original location on the screen, worked in 2.22 
- epiphany reports it has crashed, and asks for recovery. Clicking recover opens 2 instances...

If there's anything I can do to help, let me know.

thx,
jos

AFAIK the location and workspace are stored by metacity which has to reload its session. This code was changed in trunk so this might be another bug; you might want to check with an older metacity.

(In reply to comment #73)
> AFAIK the location and workspace are stored by metacity which has to reload its
> session. This code was changed in trunk so this might be another bug; you might
> want to check with an older metacity.

It might be possible that the session manager doesn't tell metacity that it was re-launched with a saved session, so metacity has no chance of picking up the old session. I didn't test which of the two scenarios is the case, but a bug in the session manager is at least quite possible.

(In reply to comment #74)
> It might be possible that the session manager doesn't tell metacity that it was
> re-launched with a saved session, so metacity has no chance of picking up the
> old session. I didn't test which of the two scenarios is the case, but a bug in
> the session manager is at least quite possible.

What I forgot is that it's also possible that the session manager didn't correctly use the restart command to re-launch the app, so metacity doesn't have a chance of identifying the app as being part of a saved session.

(In reply to comment #75)
> (In reply to comment #74)
> > It might be possible that the session manager doesn't tell metacity that it was
> > re-launched with a saved session, so metacity has no chance of picking up the
> > old session. I didn't test which of the two scenarios is the case, but a bug in
> > the session manager is at least quite possible.
> 
> What I forgot is that it's also possible that the session manager didn't
> correctly use the restart command to re-launch the app, so metacity doesn't
> have a chance of identifying the app as being part of a saved session.
> 

Indeed, the session manager does not start metacity with a session id:

jos@hamerkeuh ~ $ ps -ef | grep meta
jos       4352  4196  1 19:41 ?        00:00:00 metacity
jos       4899  4833  0 19:42 pts/0    00:00:00 grep --color meta

While some apps where restarted with a session id:

jos@hamerkeuh ~ $ ps -ef | grep sm-
jos       4358  4196  1 19:41 ?        00:00:02 gnome-panel --sm-config-prefix /gnome-panel-mh3pNx/ --sm-client-id 10fce69f15335911ca123558839526801600000246820026 --screen 0
jos       4370  4196  1 19:42 ?        00:00:01 nautilus --sm-client-id 10fce69f15335911ca123558839526884000000246820027
jos       4374  4196  0 19:42 ?        00:00:00 update-notifier --sm-config-prefix /update-notifier-CB3Nex/ --sm-client-id 1020ca61dc66a06ecd123558843647101500000255550011 --screen 0
jos       4377  4196  0 19:42 ?        00:00:00 /usr/lib/evolution/2.26/evolution-alarm-notify --sm-config-prefix /evolution-alarm-notify-IFpLZx/ --sm-client-id 10fce69f15335911ca123558839525828000000246820012 --screen 0
jos       4378  4196  2 19:42 ?        00:00:02 gkrellm --sm-client-id 103bf9169f9ec9283b123558873052581700000278430025
jos       4387  4196  0 19:42 ?        00:00:00 nm-applet --sm-disable
jos       5237  4833  0 19:44 pts/0    00:00:00 grep --color sm-
jos@hamerkeuh ~ $ 

I think I know why: metacity is already autostarted through the required_components mechanism, so when you start it again with a session ID, it is just ignored. Nautilus is probably affected in a similar way.

The solution is probably to not autostart the required components that are already in the saved session - or maybe not to start the required components at all if there is a saved session, since they all support XSMP.

(In reply to comment #77)
> I think I know why: metacity is already autostarted through the
> required_components mechanism, so when you start it again with a session ID, it
> is just ignored. Nautilus is probably affected in a similar way.

That's what I was guessing, but in comment #76, you can see nautilus and the panel with a session ID :-) But, well, it shouldn't be too hard to find out why this is happening.

(In reply to comment #70)

Ho Jon,

> Did you by any chance test this to make sure it doesn't break GDM?

I basically just disabled all session saved code in case the consolekit session type is LoginWindow. I guess this would be enough, right? 

(In reply to comment #78)
> (In reply to comment #77)
> > I think I know why: metacity is already autostarted through the
> > required_components mechanism, so when you start it again with a session ID, it
> > is just ignored. Nautilus is probably affected in a similar way.
> 
> That's what I was guessing, but in comment #76, you can see nautilus and the
> panel with a session ID :-) But, well, it shouldn't be too hard to find out why
> this is happening.

That doesn't seem to be what's happening. The code for loading a session is:  
1. load default components (gnome-settings-daemon)
2. load saved session apps (which will most likely include include gnome-panel, nautilus, metacity, etc)
3. load apps in autostart dirs
4. load required components (which will not load anything because the required components are already loaded from the saved session)

I tracked down this problem and it seems that metacity is not returning a valid restart command.

(In reply to comment #72)

Hi Jos,

> I tested svn rev 5298. 
> 
> Running apps are restarted (so far tested with gnome-terminal, epiphany,
> evolution), but:
> 
> - apps are not restored to correct desktop (evolution, epiphany), this was the
> case in 2.22 (which I'll use as a reference implementation)
> - apps are not restored to their original location on the screen, worked in
> 2.22 

Most likely a problem in metacity (as commented above). 

> - epiphany reports it has crashed, and asks for recovery. Clicking recover
> opens 2 instances...

Probably a bug in epiphany session handling. Suggest to report a bug and track this down. 

> If there's anything I can do to help, let me know.

Testing latest gdm to make sure nothing broke after the session saving additions would be useful. :-)

Thanks!

Hi,

I started metacity (svn head) in verbose mode and with a client id on the commandline:

jos@hamerkeuh metacity $ METACITY_USE_LOGFILE=1 METACITY_VERBOSE=1 metacity --replace --sm-client-id=117f000101000122548965800000199910001

In the log file I got:

SM: Initializing session with save file '(none)'
SM: Parsing saved session file /home/jos/.config/metacity/sessions/117f000101000122548965800000199910001.ms
SM: Obtained session ID '105d4bd6a23a167379123602438923536200000094710037'
Window manager: Opening display ':0.0'

And metacity does restore that session. So I think gnome-session is not starting metacity the correct way.

I have not yet tried with new gdm, as I test on ubuntu jaunty alpha, which for some reason still uses 2.20. I'll try to test with latest gdm later today.

Another update: I tried to login with the windowmanager gconf key set to metacity --sm-client-id=105d4bd6a23a167379123602478318606700000094710042. Now metacity has a client ID (as can be seen with ps), but the session is still not correctly restored (apps on wrong desktop).

Sorry for the spam...

the reason for the faulty session restore, even when specifying a session id by hand, is that the session file does not contain anything useful:

jos@hamerkeuh ~ $ cat .config/metacity/sessions/117f000101000122548965800000199910001.ms 
<metacity_session id="117f000101000122548965800000199910001">
</metacity_session>

So my guess is that gnome-session does not terminate the xsmp session correctly, that would also explain why epiphany thinks it has crashed when the session is restarted.

I've written a small xsmp client program that registers with the session manager, and logs all messages it receives. It never receives a die message:

 jos@hamerkeuh ~ $ cat /tmp/xsmp-test-FUDSPU 
IceConnectionWatch
Got client ID "1025b27d48e7ab3077123602850728053700000158060031"
ice_iochannel_watch
process ICE messages
save yourself!
ICE message: success!
ice_iochannel_watch
process ICE messages
save complete!
ICE message: success!
ice_iochannel_watch
process ICE messages
ICE message: success!
ice_iochannel_watch
process ICE messages
save yourself!
ICE message: success!
ice_iochannel_watch
process ICE messages
ICE message: success!
ice_iochannel_watch
process ICE messages
save yourself!
ICE message: success!
ice_iochannel_watch
process ICE messages
ICE message: success!
ice_iochannel_watch
process ICE messages
ICE io error
ICE message: IO error!
jos@hamerkeuh ~ $ 


Of course it is entirely possible that my little program is doing thing wrong, although I took most of the code from existing (working) xsmp client programs. I'll attach the program for scrutiny.

Created attachment 129888 [details]
simple xsmp client

Created attachment 129889 [details]
header file

A run on a system with gnome-session 2.22 gives the following output:

jos@hamerkeuh xsmp-test $ cat xsmp.log 
IceConnectionWatch
Got client ID "117f000101000123602915200000088600023"
ice_iochannel_watch
process ICE messages
save yourself!
ICE message: success!
ice_iochannel_watch
process ICE messages
save complete!
ICE message: success!
ice_iochannel_watch
process ICE messages
save yourself!
ICE message: success!
ice_iochannel_watch
process ICE messages
die!
IceConnectionWatch

In this case it *does* get the die message.

I notice that the gnome-target setting for this bug is set to 2.26. Is there any plan to get the fix being worked on here into 2.24, so the various distros that have been holding onto various 2.22-components to avoid this bug can catch up? Or is the hope that distros will skip 2.24 and go to 2.26 when this fix (hopefully) is released with it?

(In reply to comment #89)
> Is there any plan to get the fix being worked on here into 2.24

This has been already answered. See comment 52 and comment 61.

The hard code freeze for gnome 2.25 is tomorrow... meaning this ugly regression will not be fixed in gnome 2.26? Nevermind that apps are not restored at login; that's merely an annoyance. The bigger issue is that XSMP apps are not given a chance to exit cleanly.

(In reply to comment #91)
> The hard code freeze for gnome 2.25 is tomorrow... meaning this ugly regression
> will not be fixed in gnome 2.26? Nevermind that apps are not restored at login;
> that's merely an annoyance. The bigger issue is that XSMP apps are not given a
> chance to exit cleanly.

According to the previous comments, this code is already in 2.25, but metacity still needs to be fixed to report a correct RestartCommand.

the gnome-session save does not get filtered properly. I have an applet which has
Exec=/usr/lib/ospm/ospm-applet which after a couple login/logout, 3 copies of it is running including the copy from /usr/share/gnome/autostart directory,
 ptree | grep ospm-appl
              6629  /usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-X
              6656  /usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-S
              6659  /usr/lib/ospm/ospm-applet

in $HOME/.gnome2/gnome-session/saved-session
grep ospm *
10dfa650007ebba0f5123662105892043300000060280001.desktop:Name=ospm-applet
10dfa650007ebba0f5123662105892043300000060280001.desktop:Exec=/usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-SzaW3l/ --sm-client-id 10dfa650007ebba0f5123662105892043300000060280001 --screen 0
10ff35230049e0bdd5123662098169630600000057720001.desktop:Name=ospm-applet
10ff35230049e0bdd5123662098169630600000057720001.desktop:Exec=/usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-Xza40l/ --sm-client-id 10ff35230049e0bdd5123662098169630600000057720001 --screen 0

It shows the two desktop files and hence 3 copies of the applet is running.

Is that a bug or is there some desktop file attributes that needs to be set?

Created attachment 130617 [details] [review]
Patch I'm working on

This patch does two things:

 + use SmSaveBoth when we save the session. See https://listman.redhat.com/archives/xdg-list/2002-July/msg00095.html for the rationale

 + make interacting saving work (eg, for gedit). It's not perfect, though -- there's a grab taken by either the session manager or the client that makes it weird. Try it to see.

That's still not enough to have things work nicely. The other big bug might be in eggsmclient. Investigating...

(there are also some changes that shouldn't be here, namely the debug stuff and the icon size change)

Filed bug 575307 to fix the most visible issue with gedit.

Filed bug 575308 to fix gnome-terminal.

I also tried evince, and it works fine.

So, now we're left with:

 + ephy/firefox showing a restore dialog
 + metacity not saving the window positions

Both are related to how we end the session: apps seems to be killed.

(there's also my uncommitted patch, which has an issue with the interactive dialog in gedit)

Note to self: I don't think we use the discard command. We probably should do that when we remove the old saved session.

Note to self 2: might be worth saving the new session in a temp directory, then discard the old session, then rename the temp directory to saved-session. Sounds more solid.

We're clearly bad for two things:

 + we don't correctly handle SaveYourselfPhase2Request: we should remember the clients willing to do that, and send them SmsSaveYourselfPhase2 when all other clients are done.

 + it looks like we just exit when we consider the session finished, without sending a die command to the clients, nor waiting for them...

Created attachment 130627 [details] [review]
Big patch

Summary: this makes things work quite well. It'd be great to have people test this in the next 24 hours.

I should probably split the patch in multiple parts... Here are the various changes:

 + add a new end_session_last phase (after end_session), where apps that want to save their state after other apps are able to do so (phase2-stuff in xsmp). For this, we need to track the clients that reply to "saveyourself" with a "I want to save later" reply; we use next_query_clients for this.

 + use the exit phase to properly stop all clients, and introduce a new exit_now phase (after exit) which quits now; after a 10 seconds timeout, we move from exit to exit_now.

 + send the information about session-saving (via GSM_CLIENT_END_SESSION_FLAG_SAVE) to clients

 + when cancelling the session, correctly destroy the inhibitor dialog first to not go in the next phase (end_session, eg) before going back to running

 + use ~/.config/gnome-session instead of ~/.gnome2/gnome-session. Not strictly necessary, but I think it's better to go directly with the xdg dir.

 + fix the inhibitor dialog to look in all the right directories for desktop files, instead of just xdg_data_dirs

 + use smaller icons in the inhibitor dialog

 + use the discard commands when deleting an old saved session

 + enable client interaction when saving and enable client to cancel the logout

 + various protocol fixes:
   - do not send a useless initial SaveYourself on RegisterClient (this sounds wrong, since the app shouldn't save things at this point)
   - do not reply to SaveYourselfPhase2Request with SmsSaveComplete
   - always send SmsSaveComplete on SaveYourselfDone, and ignore the fact that the client couldn't succeed in saving its state since, well, we can't do anything about it so it shouldn't block the logout

(In reply to comment #100)
>  + use the discard commands when deleting an old saved session

Argh. It seems it shouldn't be done blindly since sometimes, the apps are re-using the same state file. Hrm.

Created attachment 130629 [details] [review]
Updated patch

(In reply to comment #100)
>    - do not send a useless initial SaveYourself on RegisterClient (this sounds
> wrong, since the app shouldn't save things at this point)

Looks like smclient actually expects it. Oh well. I put it back.

I also made the code a bit more solid when writing the saved desktop of a client by checking it has a restart command, and only saving the discard command if it exists (instead of, hrm, crashing ;-)).

And I disabled the use of discard commands for now: it breaks metacity session saving since metacity reuses the same session file.

Created attachment 130632 [details] [review]
Another update

In the old session manager, we compared the discard commands of the old & new saved entries and we didn't run them if there were a match.

I implemented something similar, and it works fine (metacity correctly restores the windows on workspaces again & discard commands are used).

Created attachment 130633 [details] [review]
Yet another update

There was a crash in some case when saving the session (because of a non-initialized variable)...

Filed bug 575330 for nautilus, with a trivial patch.

Vincent, are you adding back Interact and allowing client to block logout?

Also, it is really really late in the cycle for changing core design of the session like this.  Especially since this is a feature that a good number of core developers don't agree with.  I think maybe we should consider pulling all of this and wait until next cycle where we can discuss and test it properly.

(In reply to comment #106)
> Also, it is really really late in the cycle for changing core design of the
> session like this.  Especially since this is a feature that a good number of
> core developers don't agree with.  

What is the rationale for allowing the session manager to kill applications blindly and lose the user’s data ?

> I think maybe we should consider pulling all
> of this and wait until next cycle where we can discuss and test it properly.

And have another cycle during which gnome-session is unusable?

(In reply to comment #106)
> Also, it is really really late in the cycle for changing core design of the
> session like this.  Especially since this is a feature that a good number of
> core developers don't agree with.  I think maybe we should consider pulling all
> of this and wait until next cycle where we can discuss and test it properly.

Currently it doesn't do anything. Even if the new implementation is 90% broken it's still a step forward. Especially if the fixes in protocol handling force us to fix both GNOME and third party apps with regard to session handling.

Also: there are some distributions that decided to keep 2.22.x because of this bug.

William what do you disagree with exactly? 
GNOME closing sessions the way it's doing since 2.24 without considering open work and letting user save their datas is a really strong user complain for a cycle and taking quite credibility away from GNOME and something which should be fixed now and not let as an open issue for an another cycle

(In reply to comment #106)
> Vincent, are you adding back Interact and allowing client to block logout?

Yes. It turns out it integrates well with the inhibitor infrastructure (ie, there was absolutely no hack needed to make it work).

> Also, it is really really late in the cycle for changing core design of the
> session like this.

Actually, there's no real change in the core design, except maybe the addition of two phases. But the split between exit and exit_now is needed anyway to have a proper session shutdown, instead of just brutally closing X ;-) The addition of end_session_last is more debatable, but it's transparent if it's not used and it's well-separated.

All the other changes are really just bug fixes.

FWIW, I'm myself mixed on committing this for 2.26.0, but mainly because it's a big patch and it's coming really late.

I've been testing the change here starting a session, opening gedit and typing some chars, opening firefox, opening oowrite and type some chars:

before the change after closing and reopening the session: everything was close, no "do you want to save your work" questions, firefox complains about improper closing at next opening

with the change: gedit prompt for saving the work and wait it also displays the "the following program is running" dialog over it, oowrite displays the "do you want to save work" but the session close anyway rather than waiting, firefox reopen correctly and doesn't complain about the storing

the change is already a good improvement I will upload to jaunty now to get extra feedback

let me know if there is anything specific you want to get tested

(In reply to comment #110)
> (In reply to comment #106)
> > Vincent, are you adding back Interact and allowing client to block logout?
> 
> Yes. It turns out it integrates well with the inhibitor infrastructure (ie,
> there was absolutely no hack needed to make it work).

Except that it changes the entire design of the session logout.  And in a way that I and many others think is completely broken.  Even Windows realized this.

Please see http://live.gnome.org/SessionManagement/GnomeSession#head-ef7432968eb040d57a1bdea8c9552a1f3d8c4992 for a description of the design.

And for how Windows does it:
http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx
http://www.developer.com/net/cplus/print.php/3647411

The way forward should be to make applications responsible for saving their own state.  This way we have an improved user experience and a more reliable logout.  Not to mention being able to handle the case where a clean logout is not performed for any reason.

> > Also, it is really really late in the cycle for changing core design of the
> > session like this.
> 
> Actually, there's no real change in the core design, except maybe the addition
> of two phases. But the split between exit and exit_now is needed anyway to have
> a proper session shutdown, instead of just brutally closing X ;-) The addition
> of end_session_last is more debatable, but it's transparent if it's not used
> and it's well-separated.

This needs more discussion.
> All the other changes are really just bug fixes.

They are not.

> FWIW, I'm myself mixed on committing this for 2.26.0, but mainly because it's a
> big patch and it's coming really late.

It is too late.  Let's have start a discussion early next cycle and involve the following: owen, hp, walters, vuntz, lucasr, mccann, halfline (or any other core developers that have a deep understanding of the issues).  Sound reasonable?

(In reply to comment #112)
> The way forward should be to make applications responsible for saving their own
> state.  This way we have an improved user experience and a more reliable
> logout.  Not to mention being able to handle the case where a clean logout is
> not performed for any reason.

While I agree with you here I don't think saying "now that we've cahnged our minds, screw you current desktop users and screw you third party apps, we'll leave you broken until we come up with a better architecture" is polite.

It's entirely possible to fix the current session handling, create a better alternative (mind you there's no reason they would collide when working in parallel) and mark the current approach as deprecated. Then drop it after one or two cycles so apps get their chance of doing stuff the new way (a GNOME Goal perhaps?).

If vuntz' patch fixes issues from a user point of view and does not make it *way* more work for developers to fix the hereby introduced "completely broken design" in the next cycle I tend to get this in, for the sake of user happiness.

what about getting the change in 2.26.1 rather than 2.26 that let some time for testing

(In reply to comment #112)
> Let's have start a discussion early next cycle and involve the
> following: owen, hp, walters, vuntz, lucasr, mccann, halfline (or any other
> core developers that have a deep understanding of the issues).  Sound
> reasonable?

danw at the head of that list obviously.

Sebastien, I know it's a bug and so on, but it's not very nice to have the Desktop documentation saying that GNOME *saves* the sessions while knowing it does not. 

I don't know what is better, to have a, perhaps, buggy session saving, or not having anything at all.

I'm fine with GNOME having a completely broken and ugly session management. It's far imrpoved compared to 2.24, as othershave pointed out. And if it does things wrong or stuff needs a discussion, we can still change it for 2.28.

And if this change needs more testing, I'd say we delay the release until we get it in. Releasing 2.24 without session support was already a big blunder, but releasing 2.26 without it, even though we knew for half a year that it was the most requested feature is just bad engineering and not listening to users.

(In reply to comment #112)
> (In reply to comment #110)
> > (In reply to comment #106)
> > > Vincent, are you adding back Interact and allowing client to block logout?
> > 
> > Yes. It turns out it integrates well with the inhibitor infrastructure (ie,
> > there was absolutely no hack needed to make it work).
> 
> Except that it changes the entire design of the session logout.  And in a way
> that I and many others think is completely broken.  Even Windows realized this.
> 
> Please see
> http://live.gnome.org/SessionManagement/GnomeSession#head-ef7432968eb040d57a1bdea8c9552a1f3d8c4992
> for a description of the design.

Yes. I know that page. And I fail to see what's wrong with the patch wrt this. Eg, the wiki page mentions "This state may last a certain time (TBD) or until all proactively indicated tasks (aka "inhibitors") have finished.", which is exactly what's happening. Sure, clients should not assume that they will have the ability to block logout, but that's up to clients.This is all handled correctly, IMHO.

> The way forward should be to make applications responsible for saving their own
> state.

I don't understand -- that's already the case.

> Not to mention being able to handle the case where a clean logout is
> not performed for any reason.

This is not the case: the user is told about a blocking logout and can force it.

[...]

> > All the other changes are really just bug fixes.
> 
> They are not.

Heh. "They are" would be my reply ;-) Seriously. I just fixed stuff to respect the protocol.

> > FWIW, I'm myself mixed on committing this for 2.26.0, but mainly because it's a
> > big patch and it's coming really late.
> 
> It is too late.  Let's have start a discussion early next cycle and involve the
> following: owen, hp, walters, vuntz, lucasr, mccann, halfline (or any other
> core developers that have a deep understanding of the issues).  Sound
> reasonable?

I'm perfectly fine with discussing the future of session saving. However, I disagree with us not reimplementing correct xsmp support without anything else instead. I'm not using session saving, and I only care about it because we got really bad comments from people about it. Which is why this should be fixed ASAP.

(In reply to comment #111)
> with the change: gedit prompt for saving the work and wait it also displays the
> "the following program is running" dialog over it, oowrite displays the "do you
> want to save work" but the session close anyway rather than waiting, firefox
> reopen correctly and doesn't complain about the storing

That's actually a crash in gsm-inhibitor-dialog.c. Attaching an updated patch with the fix.

Created attachment 130659 [details] [review]
Add fix for crash when OOo is in the session

(In reply to comment #119)
[snip]
> I'm perfectly fine with discussing the future of session saving. However, I
> disagree with us not reimplementing correct xsmp support without anything else
> instead. I'm not using session saving, and I only care about it because we got
> really bad comments from people about it. Which is why this should be fixed
> ASAP.
> 

being an actual user of this, i completely agree with the above.  there is _NO_
session saving capability now so any attempt to get this fixed in the pending
release is entirely welcome even if it isn't "perfect".

this bug has been open since 2.24 was released (possibly even before) and its
just now getting some attention?  there have been continual complaints because
there wasn't any activity which were then jumped on with the comment that work
was happening and to stop asking.  now we see no real work that would allow
some user testing was being done until now?

this is easily my biggest pet peave with the GNOME desktop right now.  the
session save capability (imperfect as it may be) was ripped away from the users
in the 2.22 -> 2.24 transition without hardly a thought. now there is push back
on putting the functionality back?  come on folks - there are people actually
trying to get work done using FOSS software.  it isn't just a software
engineering experiment.

I understand the time and life constraints on so many open source developers that don't always leave the time necessary for perfect implementation of changes. So I'm not blaming vuntz for doing this now, I just really appreciate that it's finally getting done! You rock, dude!

But comment 122 is right on one thing, this is disrupting the workflow for so many of us who have commited to using Gnome as our workspace. We don't have a usability lab to see how the changes in each cycle impact users, so when you get so much negative feedback this is unfortunately the only way to know something's wrong. Please go forward with this for 2.26.0, it's badly needed for many of us!

> I'm perfectly fine with discussing the future of session saving. However, I
> disagree with us not reimplementing correct xsmp support without anything else
> instead. I'm not using session saving, and I only care about it because we got
> really bad comments from people about it. Which is why this should be fixed
> ASAP.

This is not how we should be making our decisions.  Fixing the gaps in the new design is a better way to spend our time - and sends a clear signal to application authors.  This feature was/will be committed after ever freeze date, without testing, with objections from one of the authors of the code, despite general agreement among many core developers that xsmp style saving is broken and provides a poor user experience.

The user experience of dropping this feature entirely without giving application developers time to switch to an accepted, standardized protocol is much, much worse. This major regression shouldn't have hit 2.24 in the first place, and releasing 2.26 without correcting it is, frankly, irresponsible and demoralizing to people hoping to see Gnome adoption increase.

(In reply to comment #124)
> This is not how we should be making our decisions.  Fixing the gaps in the new
> design is a better way to spend our time - and sends a clear signal to
> application authors.

In the long run I totally agree. But in the short run there's also users out there. I think it can't get much worse from a user POV. And /me as a user simply don't care about your design as long as it works for me.

(In reply to comment #124)
> This is not how we should be making our decisions.  Fixing the gaps in the new
> design is a better way to spend our time - and sends a clear signal to
> application authors.  

What signal? That they need to implement a new protocol which is not even standardized in freedesktop and uses a GNOME-specific namespace in D-Bus? Do you really think this is going to happen?

Furthermore, we currently ship in Debian (quick estimation) around 900 applications using XSMP. Do you have any idea of the amount of work to port even a reasonable subset of these applications? Do you think users can accept that all applications that haven’t be ported aren’t supported correctly? Even worse, do you think you can remove XSMP support in GNOME applications and let them fail when started with other session managers?

> This feature was/will be committed after ever freeze
> date, without testing, with objections from one of the authors of the code,
> despite general agreement among many core developers that xsmp style saving is
> broken and provides a poor user experience.

Yes, it’s a good thing to replace a broken protocol by another one. But you need to do it correctly:
 - Get the protocol to be standardized.
 - Convince other session managers to implement the protocol.
 - Have a transition time during which both protocols are supported. A transition time long enough to fix hundreds of applications. Yes, that means several years.

Given that XSMP is a mess of bizarre special cases and buggy client implementations, and in the past it has *frequently* been the case that broken clients have caused problems for the session manager (and by extension, the session as a whole), and given that Vincent clearly was not terribly familiar with the gory details of XSMP when he started this, as shown by comment #101 and comment #102, I suspect there are still bugs in the patch, and there will still be bugs in it on Wednesday. (As a concrete example, I'd suggest that someone test out the patch with Skype running, qv bug 357539.)

OTOH, the worst case scenarios are probably either (a) gnome-session crashes when you try to log out, or (b) gnome-session doesn't let you log out, and you have to killall it or power-cycle. While these would both *look* really bad for us, neither is actually all that different from "gnome-session doesn't save your session and then kills apps without calling SmsDie()". So...

Vincent, you should read http://live.gnome.org/SessionManagement/NotesOnXSMP :)

(In reply to comment #124)
> > I'm perfectly fine with discussing the future of session saving. However, I
> > disagree with us not reimplementing correct xsmp support without anything else
> > instead. I'm not using session saving, and I only care about it because we got
> > really bad comments from people about it. Which is why this should be fixed
> > ASAP.
> 
> This is not how we should be making our decisions.  Fixing the gaps in the new
> design is a better way to spend our time - and sends a clear signal to
> application authors.

I strongly disagree: the clear signal will be sent when we'll have session management in GTK+. And this is the opportunity we'll have to fix things.

However, that doesn't mean we should ignore all the already-existing apps. And it's not just about saving a session, but about properly talking xsmp with the clients. Do you really think it's fine to have the session exit while your OOo document hasn't been saved? Because that's what is happening right now. Out of all the possible solutions, the current behavior is one of the worse (if not the worst) we could do.

(not arguing about what I do with my time ;-))

> This feature was/will be committed after ever freeze date, without testing,

My patch wasn't committed and I'm still unsure what to do with it for 2.26.0.

The coder and maintainer in me says "request a freeze break!", while the release team member part of my brain clearly knows it's really bad to commit such a patch at this stage. That's also why I asked more people to test this.

> with objections from one of the authors of the code,
> despite general agreement among many core developers that xsmp style saving is
> broken and provides a poor user experience.

Sure it's broken and it provides a poor user experience (although I could argue it's not that bad). I think everybody agrees a better solution has to be found in the long term. But we also have to look at what people need now.

Did you look at the patch? Nearly all the things that are changes are either needed anyway (xsmp or not) or xsmp-related (so they won't matter in a non-xsmp solution).

The only change that is debatable outside of xsmp is the introduction of end_session_last. My opinion is that it's some really small part in the code that can be easily removed in the future if we think it's wrong.

FWIW, I agree with Sebastien and Jon on this.  

I realize this is a feature that many people want to see back sooner rather than later.  In fact, it's a feature that they would rather already have had.  But this isn't about the feature.  It's about the patch.  2.26.0 is really, really soon.  There's no way we can be sure the patch even implements the feature. It may seem like it does in broad strokes, but look, we all know from experience that code commited at the last minute without testing is *inevitably* broken code.

Applying it for .0 would't be responsible release engineering.  In my opinion, it shouldn't even be on the table.  GNOME has been doing speedy, regular releases for years and years now. We're good at it, and we know better than this.

Whether it should be done in the 2.26 series is another question.  And really, if it were decided that shipping in 2.26 was the right thing to do, shipping it in a tarball a month from now wouldn't practically speaking be that much worse than the shipping it in tarball less than a week from now.  Most of the users who really miss this feature aren't going to upgrade between now and then anyway.

(In reply to comment #130)
> Whether it should be done in the 2.26 series is another question.  And really,
> if it were decided that shipping in 2.26 was the right thing to do, shipping it
> in a tarball a month from now wouldn't practically speaking be that much worse
> than the shipping it in tarball less than a week from now.  Most of the users
> who really miss this feature aren't going to upgrade between now and then
> anyway.

I think the important question here is "will GNOME 2.26 work with gnome-session 2.22?" The packager in me tells me distros will either stick with GNOME 2.24 or patch 2.26.0 to include this code anyway.

> Applying it for .0 would't be responsible release engineering.  In my opinion,

Ray, be sure I share your concern but this bug report gained such publicity that
the release team decision on this matter can't be driven by technical
considerations alone, there is some "GNOME image" at stake here; that can't be
ignored, for best or worst.

Those patches are currently being tested by many users, and its final inclusion,
now, or later in 2.26.x, or in 2.27, will most certainly be decided very late,
and it will be a carefully measured decision.

Hi,

I can confirm that this patch makes session saving work good enough for me (svn + this patch). The 2.25.92 release is a LOT worse. This patch restores the session for epiphany, evolution, gnome-terminal (I had to downgrade to gnome-terminal 2.22 to make this work, it seems session management in the current gnome-terminal is broken, should I file a separate bug for this?).

Please apply this patch, the chance for regression is zero, as the functionality was (and is still in the current 2.25.92 release) completely borked anyway. I find it hard to believe that you are doubting a *working* patch, but don't hesitate to REMOVE functionality that a lot of users depend on, and that most users didn't consider broken in the first place!

Jos

I found two issue with the latest patch.

1. evolution-data-server process is increased.
2. unable to shutdown the session occasionally.

(In reply to comment #134)
> I found two issue with the latest patch.
> 
> 1. evolution-data-server process is increased.

What do you mean?

> 2. unable to shutdown the session occasionally.

Close the session or run shutdown? Do you have more details? (what apps are running, eg)

(In reply to comment #135)
> (In reply to comment #134)
> > I found two issue with the latest patch.
> > 
> > 1. evolution-data-server process is increased.
> 
> What do you mean?

After the first logged in (no restoring session), run evolution, then one evolution-data-server is spawned. 
Then logged out with saving session, and logged int again. There is another evolution-data server process. So there are two eds processes.

> > 2. unable to shutdown the session occasionally.
> 
> Close the session or run shutdown? Do you have more details? (what apps are
> running, eg)

Shutdown in system menu. I am not sure when this issue is occurred. But I guess this issue is related to comment #128.

(In reply to comment #136)
> (In reply to comment #135)
> > (In reply to comment #134)
> > > I found two issue with the latest patch.
> > > 
> > > 1. evolution-data-server process is increased.
> > 
> > What do you mean?
> 
> After the first logged in (no restoring session), run evolution, then one
> evolution-data-server is spawned. 
> Then logged out with saving session, and logged int again. There is another
> evolution-data server process. So there are two eds processes.

Sounds like evolution-data-server is saved in the session, while it shouldn't. That would be an eds bug. Can you check that there's a file for it in ~/.config/gnome-session/saved-session/?

> > > 2. unable to shutdown the session occasionally.
> > 
> > Close the session or run shutdown? Do you have more details? (what apps are
> > running, eg)
> 
> Shutdown in system menu. I am not sure when this issue is occurred. But I guess
> this issue is related to comment #128.

Hrm, there's nothing specific in comment #128 that could explain this. Without being able to reproduce the problem or knowing a bit more about what was running in the session, I won't be able to fix the problem. (Note that shutdown vs logout shouldn't matter)

(In reply to comment #137)
> (In reply to comment #136)
> > (In reply to comment #135)
> > > (In reply to comment #134)
> > > > I found two issue with the latest patch.
> > > > 
> > > > 1. evolution-data-server process is increased.
> > > 
> > > What do you mean?
> > 
> > After the first logged in (no restoring session), run evolution, then one
> > evolution-data-server is spawned. 
> > Then logged out with saving session, and logged int again. There is another
> > evolution-data server process. So there are two eds processes.
> 
> Sounds like evolution-data-server is saved in the session, while it shouldn't.
> That would be an eds bug. Can you check that there's a file for it in
> ~/.config/gnome-session/saved-session/?

There is no eds entry.

zoe-laptop% grep -r evolution .config/gnome-session/saved-session/
.config/gnome-session/saved-session/10f183c3d7496c911e123715758437906100000171650039.desktop:Exec=/usr/lib/evolution/2.26/evolution-alarm-notify --sm-config-prefix /evolution-alarm-notify-YRzA7w/ --sm-client-id 10f183c3d7496c911e123715758437906100000171650039 --screen 0
.config/gnome-session/saved-session/10f183c3d7496c911e123715758437906100000171650039.desktop:X-Ubuntu-Gettext-Domain=evolution-2.26
.config/gnome-session/saved-session/10f183c3d7496c911e123715758299547700000171650037.desktop:Exec=evolution --sm-config-prefix /evolution-jko93U/ --sm-client-id 10f183c3d7496c911e123715758299547700000171650037 --screen 0
.config/gnome-session/saved-session/10f183c3d7496c911e123715758299547700000171650037.desktop:Icon=evolution
.config/gnome-session/saved-session/10f183c3d7496c911e123715758299547700000171650037.desktop:X-GNOME-Bugzilla-OtherBinaries=evolution-data-server-2.26;evolution-exchange-storage;evolution-alarm-notify;
.config/gnome-session/saved-session/10f183c3d7496c911e123715758299547700000171650037.desktop:X-Ubuntu-Gettext-Domain=evolution-2.26
.config/gnome-session/saved-session/106dbfc3ae5b19b8bf123715833477728400000035720034.desktop:Name=evolution-exchange-storage
.config/gnome-session/saved-session/106dbfc3ae5b19b8bf123715833477728400000035720034.desktop:Exec=evolution-exchange-storage --sm-config-prefix /evolution-exchange-storage-o9YTix/ --sm-client-id 106dbfc3ae5b19b8bf123715833477728400000035720034 --screen 0

 
> > > > 2. unable to shutdown the session occasionally.
> > > 
> > > Close the session or run shutdown? Do you have more details? (what apps are
> > > running, eg)
> > 
> > Shutdown in system menu. I am not sure when this issue is occurred. But I guess
> > this issue is related to comment #128.
> 
> Hrm, there's nothing specific in comment #128 that could explain this. Without
> being able to reproduce the problem or knowing a bit more about what was
> running in the session, I won't be able to fix the problem. (Note that shutdown
> vs logout shouldn't matter)

OK. I will report with detail info if the issue happens again.

(In reply to comment #136)
> After the first logged in (no restoring session), run evolution, then one
> evolution-data-server is spawned. 
> Then logged out with saving session, and logged int again. There is another
> evolution-data server process. So there are two eds processes.

Oh, I actually misunderstood: do you mean that after logging out, evolution-data-server is still running? (you can check by logging in a console)

(In reply to comment #139)

> Oh, I actually misunderstood: do you mean that after logging out,
> evolution-data-server is still running? (you can check by logging in a console)

Ah, yes. But if my memory serves right, eds behaves that way before.

(In reply to comment #124)
> > I'm perfectly fine with discussing the future of session saving. However, I
> > disagree with us not reimplementing correct xsmp support without anything else
> > instead. I'm not using session saving, and I only care about it because we got
> > really bad comments from people about it. Which is why this should be fixed
> > ASAP.
> 
> This is not how we should be making our decisions.  Fixing the gaps in the new
> design is a better way to spend our time - and sends a clear signal to
> application authors.  This feature was/will be committed after ever freeze
> date, without testing, with objections from one of the authors of the code,
> despite general agreement among many core developers that xsmp style saving is
> broken and provides a poor user experience.
> 

To be fair, this bug has been flagged as a blocker since 2.4. While it is reasonable to object bug changes in such late stage of the release. It is unreasonable to break a major feature in the first place without a clear timeline road map for the feature! Have there been a estimated timeline roadmap, distros may decide whether to stick with 2.22 for a little while before upgrading. These lines of communication has not been clear.

On the technical side while xsmp is broken, there isn't a very clear indicator what is the alternative implementation nor recommendation as such.

(In reply to comment #141)
> To be fair, this bug has been flagged as a blocker since 2.4.

2.24.

Thanks Andre for the correction.

I have created bug http://bugzilla.gnome.org/show_bug.cgi?id=575544 and has attached a patch that allow the gnome-session-properties dialog to have the Remember current running application button to save session. 

Most of the dbus code were copied from tools/gnome-session-save.c. I will also create another bug fro the gnome-session-save bit later.

Hey Vincent, some quick comments on the patch;

1. gsm_util_get_desktop_dirs implementation could simply use a GPtrArray instead of doing this calculation of array sizes;

2. I still don't see the need for a new EXIT_NOW phase. You can just call gtk_main_quit() when EXIT phase ends (which is what the current code does).

3. Re-enabling client interact conceptually clashes with current design (as mccann already commented). The major symptom of this is described by Sebastien: "gedit prompt for saving the work and wait it also displays the "the following program is running" dialog over it". This means we'd have two user-visible ways of handling "client not ready for logout" case.

About 3, we have a tricky situation here. Vincent's patch make g-s be more compliant with XSMP protocol. On one hand, this is a good thing because this makes g-s behave just like current XSMP session clients expect and, consequently, makes current session management work better. One the other hand, it clashes with the fundamental advantage of the new session management design that brings a better user experience in my opinion. In order to make the new design actually work with current XSMP client implementations, we'd have to change the way applications manage their state (as pointed by Jon) and not requesting interaction from the user and blocking logout. So, here are three important facts about the 2.26 release: 

1. Current XSMP client implementations are not behave the way we want;

2. We won't be able to change all major applications to behave the way we want with the new session management design for 2.26. Especially because some of them are not in the GNOME scope (Firefox, OOo, etc).

3. The combination of not having applications behaving as per the new design and having a session manager that doesn't follow the XSMP protocol means that users may *lose data* because apps are expecting the user to explicitly save their data on logout.

So, here's my super-pragmatic way of seeing this is:

1. GNOME Session Manager should support current implementation of XSMP clients until we have a new official protocol in place. By "official protocol", I mean a D-Bus protocol that is agreed at least between KDE and GNOME.

2. Propose new D-Bus based session management protocol on fd.o asap. Jon made an excellent work on designing and implementing a new protocol in gnome-session. This should be more than enough to start a discussion. The co-located Akademy+GUADEC will be a nice opportunity to discuss and decide this still for 2.28.

3. During 2.27.x cycle, we should consider any use of XSMP's Interact as bug in our apps. Having XSMP Interact actually implemented in gnome-session will help us finding those bugs. Also, as soon as we have all our apps not using XSMP interact and correctly handling their state, this will make it much easier to move to the new protocol.

Hence, here's a suggested plan:

1. Disable session saving on 2.26.0 (as it's not correctly working without Vincent's patch);

2. Vincent commits his patch just after 2.26.0 so that it can be tested until the 2.26.1 release;
  2.1. If everything goes fine (no major bugs and crashes), we keep the code for 2.26.1.
  2.2. If something goes really bad, we disable the code for 2.26.1 and try to fix any major issues for 2.26.2.

The major drawback for 2.26 would be that we'll show the inhibitors dialog *and* the logout interaction dialogs on each session client application. Not sure if this would be fixable at this point.

(In reply to comment #144)
> Hey Vincent, some quick comments on the patch;
> 
> 1. gsm_util_get_desktop_dirs implementation could simply use a GPtrArray
> instead of doing this calculation of array sizes;

Will do.

> 2. I still don't see the need for a new EXIT_NOW phase. You can just call
> gtk_main_quit() when EXIT phase ends (which is what the current code does).

No: you want to leave a chance to clients to properly exit (sending a Die xsmp message, or Stop dbus message) before the session manager (and therefore X) stops.

> 3. Re-enabling client interact conceptually clashes with current design (as
> mccann already commented). The major symptom of this is described by Sebastien:
> "gedit prompt for saving the work and wait it also displays the "the following
> program is running" dialog over it". This means we'd have two user-visible ways
> of handling "client not ready for logout" case.

Feature, not a bug: if gedit is on another workspace, you know it's blocking the logout. Without the gnome-session dialog, you're wondering what's going on.

[not commenting on the long-term proposed plan; I'll focus on that once we have the 2.26 situation handled -- although I'd point out that most of the issues people have with xsmp is with this third item, which I think is really a feature]

(In reply to comment #137)
> (Note that shutdown vs logout shouldn't matter)

I remove this comment :-) I'll try to fix this.

> > 3. Re-enabling client interact conceptually clashes with current design (as
> > mccann already commented). The major symptom of this is described by Sebastien:
> > "gedit prompt for saving the work and wait it also displays the "the following
> > program is running" dialog over it". This means we'd have two user-visible ways
> > of handling "client not ready for logout" case.
> 
> Feature, not a bug: if gedit is on another workspace, you know it's blocking
> the logout. Without the gnome-session dialog, you're wondering what's going on.
> 

I agree with Vinz here, I have often had this case that some app was blocking 
logout and I was wondering why, and then finding a dialog on another workspace.

Lucas's plan seems very sensible to me.

Looking on as an outsider (as a GNOME user, but a Qt application developer) I
think it's vital to support XSMP until a replacement has been accepted and
implemented across at _least_ GTK and Qt.

It would arguably be worse to have support only for a system that a few
privileged applications use than to have no support at all, because (a) it
would make the behaviour even less predictable for the user and harder to deal
with correctly [if e.g. inkscape asks to save changes but scribus silently
loses them], and (b) politically it might look like a deliberately unhelpful
policy on GNOME's part rather than an mistake made with good intentions as is
clearly the case with this bug.

Whatever happens, a number of users will continue using programs that are never
updated to any newer protocol, either for technical reasons or because of
stagnation.  (I have at least one Xlib application myself that works nicely
with XSMP but will likely never use D-BUS.)  But the numbers of these should be
small enough for workarounds like explicit use of autostart to be acceptable
instead... so long as the replacement for XSMP is an improvement in other ways.
 So I think coverage in the two or three main toolkits should be enough, but I
do think that that is necessary.

Whatever the outcome, I'm truly grateful for all the work that Vincent, Lucas
and others are putting in to resolve this thorny problem.


Chris

(In reply to comment #147)
> > > 3. Re-enabling client interact conceptually clashes with current design (as
> > > mccann already commented). The major symptom of this is described by Sebastien:
> > > "gedit prompt for saving the work and wait it also displays the "the following
> > > program is running" dialog over it". This means we'd have two user-visible ways
> > > of handling "client not ready for logout" case.
> > 
> > Feature, not a bug: if gedit is on another workspace, you know it's blocking
> > the logout. Without the gnome-session dialog, you're wondering what's going on.
> > 
> 
> I agree with Vinz here, I have often had this case that some app was blocking 
> logout and I was wondering why, and then finding a dialog on another workspace.

I have often wondered the same thing, but it is hardly intuitive that the user has to start searching for blocking applications on other workspaces. Not sure how it should behave, but I guess that somehow raising the window in the current workspace would be a good start.

(In reply to comment #127)
 
> Yes, it’s a good thing to replace a broken protocol by another one. But you
> need to do it correctly:
>  - Get the protocol to be standardized.
>  - Convince other session managers to implement the protocol.
>  - Have a transition time during which both protocols are supported. A
> transition time long enough to fix hundreds of applications. Yes, that means
> several years.
> 

It is my hope that the gate keepers for the GNOME release have gotten the message that it was a mistake with 2.24 to delete session save functionality, and to leave it regressed for one, possibly two, possibly more release cycles.

Please commit the fixes for the regressed behavior.  Going forward, please approach other big changes with an approach that gives users a smooth migration path, not a multi-month loss of functionality.

In Open Source we work towards good implementations.

But if we too often sacrifice usability, the users, who often don't care HOW the product is implemented, walk away from our clean, Open Source solution. They switch to the poorly written proprietary implementation for no better reason than, "The thing that didn't work on the Open Source system works for me with this other system."

FWIW: I released gnome-session 2.26.0 without this patch because it hadn't been tested enough, and we actually disabled the session saving support there since it was not in a good enough shape. The goal is to have all this in 2.26.1.

(In reply to comment #151)
> FWIW: I released gnome-session 2.26.0 without this patch because it hadn't been
> tested enough, and we actually disabled the session saving support there since
> it was not in a good enough shape. The goal is to have all this in 2.26.1.
> 

i want to applaud and encourage vincent and others' work on fixing this issue.  i for one greatly appreciate it.

at the same time, i want to chastise the GNOME maintainers and release keepers for creating this situation in the first place before 2.24 was released.  i sincerely wish a similar amount of concern and consternation for release practices had been exercised on the 2.24 release and we wouldn't be in this place.

however, i do understand two wrongs don't make a right and the release plan to include the functionality in 2.26.1.  please just learn from this and move forward.  open source has enough issues without intentionally regressing an application which then frustrates and turns away users.

I found another issue.

After restoring session with some applications, then quit all the applications and disable "Automatically remember running applications when logging out" option, next time I logged in, applications which were restored at the last logged in time are restored again.

Vincent, is this intended or not?

(In reply to comment #153)
> I found another issue.
> 
> After restoring session with some applications, then quit all the applications
> and disable "Automatically remember running applications when logging out"
> option, next time I logged in, applications which were restored at the last
> logged in time are restored again.

Hmm, this is a bug. We should clear saved session data when you logout on a session with disabled auto saving. Vincent, could you update the patch with this?

(In reply to comment #154)
> Hmm, this is a bug. We should clear saved session data when you logout on a
> session with disabled auto saving. Vincent, could you update the patch with
> this?

I think such behavior would break manual session saving. If you save your session manually in the session properties, you want it to be restored each time. 

Agree with Josselin. We should probably either add a "clear saved session" button or make unchecking "Automatically remember..." clear the saved session.

The second one potentially breaks a use case (save on logout once, use forever).

Is the Session (editor) tab in the Control Center's Session applet going to come back?

(In reply to comment #157)
> Is the Session (editor) tab in the Control Center's Session applet going to
> come back?

No, this belongs to gnome-system-monitor. See bug 421912.

(In reply to comment #155)
> (In reply to comment #154)
> > Hmm, this is a bug. We should clear saved session data when you logout on a
> > session with disabled auto saving. Vincent, could you update the patch with
> > this?
> 
> I think such behavior would break manual session saving. If you save your
> session manually in the session properties, you want it to be restored each
> time. 

I don't know how much (if any) of this is left in the current gnome-session code, but my original plan was that there would be two separate saved sessions, one for the "default session", and one for "the state at last logout". Saving the session on logout would only apply to the next login, while saving the session from the capplet would affect the "default session". When gnome-session started up, it would first check if there was a saved-at-logout session, and if so, it would resume it *and then immediately discard it*. If there wasn't a saved-at-logout session, it would check if there was a default session, and if so, it would resume (and NOT discard) that. If there wasn't either kind of saved session, it would just load the default session.

That approach breaks on system crashes, as during a running session neither the previous nor the current data is available.
I'm not sure what the desired behavior is in this case - restart with last session or with empty session. (I prefer last session.)

(Also, I might be reading too much about ext4 problems and applying that knowledge to saved sessions)

(In reply to comment #155)
> (In reply to comment #154)
> > Hmm, this is a bug. We should clear saved session data when you logout on a
> > session with disabled auto saving. Vincent, could you update the patch with
> > this?
> 
> I think such behavior would break manual session saving. If you save your
> session manually in the session properties, you want it to be restored each
> time. 
 
Oh, you're right. I think this was a subconscious reaction to the fact that manual session saving is not working now :-P

I like danw's suggestion.

The problem with manually saved sessions is that there's no UI to check what apps are in it...

(In reply to comment #161)
> (In reply to comment #155)
> > (In reply to comment #154)
> > > Hmm, this is a bug. We should clear saved session data when you logout on a
> > > session with disabled auto saving. Vincent, could you update the patch with
> > > this?
> > 
> > I think such behavior would break manual session saving. If you save your
> > session manually in the session properties, you want it to be restored each
> > time. 
> 
> Oh, you're right. I think this was a subconscious reaction to the fact that
> manual session saving is not working now :-P
> 
> I like danw's suggestion.
> 
> The problem with manually saved sessions is that there's no UI to check what
> apps are in it...
> 

in the interests of getting at least a single saved session, please implement one single thing ASAP:  a single button that implements "Save current session".

the rest of the discussion is fine - just don't let it detract from getting at _LEAST_ that functionality in.   the UI for managing the single button above is to look at your current session and if it is what you want to come up when you login each time then press the button.   if i want to change it later, i'll push the button again after re-arranging the apps. 

thanks.

(In reply to comment #160)
> That approach breaks on system crashes, as during a running session neither the
> previous nor the current data is available.

This is unfortunate, but it's no different from the behavior of laptop suspend/resume in the face of crashes; if I resume my laptop, do some work, and then it crashes and I have to reboot, it reboots to a clean slate, not back to the state it was in when I last resumed. It's not a bug per se, it's just that the model doesn't make any effort to deal with system crashes.

If we were going to try to deal with crashes, I think we'd want some way to do "autosaves", so that you could actually resume the *current* session state, not the previous state. But XSMP doesn't give us a good way to do this. (It gives us bad ways to do it, but... they're bad.)

(In reply to comment #159)
> When gnome-session started up, it would first check if there was a saved-
> at-logout session, and if so, it would resume it *and then immediately
> discard it*.

Any reason why we'd not discard it on the next logout? This would fix Benjamin's issue, I guess.

(In reply to comment #164)
> (In reply to comment #159)
> > When gnome-session started up, it would first check if there was a saved-
> > at-logout session, and if so, it would resume it *and then immediately
> > discard it*.
> 
> Any reason why we'd not discard it on the next logout? This would fix
> Benjamin's issue, I guess.

My preferred behavior for session management as a user is as follows:

I would prefer one session file for a manual saved session,
and one session file for the "the state at last logout",
like in comment #159.

The session file for the manual saved session is only deleted on request by the user, or by being replaced by a new manual saved session. The replace should handled by first creating a new manual saved session file with a new (temporary) name and then renamed (moved) to the standard session file name for the manual saved session. Before renaming the file size should be checked that it is not empty (for example because the there was no free space on the file system or the file system quota for the user was reached). Using this method the user should have either the old or the new manuel session file.

The session file for the state at last logout should be handled in the same way when an new saved session file is created at logout if the user has requested to restore the last state at logout on the next login. Then there is always a last saved session file even in the case of a crash.

If the user changes the preference to not to save the state at logout, then the corresponding last saved session file can be removed immediately.

One user interface for saving the manual saved session is the current desktop with the arranged applications on the workspaces. The dialog for saving the session should not be part of the manual saved session.

If there would be a graphical interface to show and modify what was saved as the manual saved session would be nice, but it is not so much important. Sometimes there are running some applications and applets in the background that the user doesn't see when he saves a session manually. The list of applications and applets (?) can been shown by such a graphical interface, and it should be possible to remove some of that listed applications or modify them, and manually add applications to the list, and save the new list.
But if this can also be done by editing the manual saved session file (if it is a plan text file) and the format of the file is well documented so the user can know how to modify it right, then this may be an alternative for experienced users while there is no graphical interface.

(In reply to comment #165)
> I would prefer one session file for a manual saved session,
> and one session file for the "the state at last logout",
> like in comment #159.

An addition: The advantage with two different saved state files is that the manual saved session is not lost when the user switches between restoring the session on logout or not.

(In reply to comment #165)
> The session file for the state at last logout should be handled in the same way
> when an new saved session file is created at logout if the user has requested
> to restore the last state at logout on the next login. Then there is always a
> last saved session file even in the case of a crash.

One more addition: Autosaving the current session like suggested in comment #163 can be added to this model.

We can also save versions of that saved session state files. The number of version of that files (autosave files, logout session state files, manual saved session files) should be configurable, and if more versions of that files are present then that older versions should been removed automatically so the used disk space remains small and limited.

Gentoo's Gnome overlay included the session-save patch with gnome-session 2.26.0 for testing.

With the current implementation, there are gnome-terminal-<timestamp>.desktop files saved in .config/session-state/ that contain the correct information on number of tabs and directories those tabs are in. However the terminal that starts up has a single tab in the home directory. Should that be a separate gnome-terminal bug?

Can I assume that once a final direction for session saving is determined, that the older session files will be deleted?

I'm also having issues with firefox thinking it has crashed on the prior logout, but I'm also using avant-window-navigator instead of the panel so I don't know if its logout applet is responsible for this. Since the session save info seems to be there for other applications it may simply be firefox not handling the session end correctly.

(In reply to comment #168)
> I'm also having issues with firefox thinking it has crashed on the prior
> logout, but I'm also using avant-window-navigator instead of the panel so I
> don't know if its logout applet is responsible for this.

Apparently so. Now that an updated gnome-desktop-sharp is available and gnome-do is working again, I can logoout from there and when I login firefox starts normally.

The gnome-terminal issue is the same however. I just noticed comment 133 refers to this same issue.

(In reply to comment #168)

> With the current implementation, there are gnome-terminal-<timestamp>.desktop
> files saved in .config/session-state/ that contain the correct information on
> number of tabs and directories those tabs are in. However the terminal that
> starts up has a single tab in the home directory. Should that be a separate
> gnome-terminal bug?

The issue is bug 575308.

Ghee:

(In reply to comment #93)
> the gnome-session save does not get filtered properly. I have an applet which
> has
> Exec=/usr/lib/ospm/ospm-applet which after a couple login/logout, 3 copies of
> it is running including the copy from /usr/share/gnome/autostart directory,
>  ptree | grep ospm-appl
>               6629  /usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-X
>               6656  /usr/lib/ospm/ospm-applet --sm-config-prefix /ospm-applet-S
>               6659  /usr/lib/ospm/ospm-applet

That's actually a tough thing to handle correctly for the session manager. I would think the conclusion here is that if an app is expected to be autostarted, it should either:

 + not be saved in the session
 + set a X-GNOME-Provides key in its desktop file to something unique (this way, the saved client will mask the one from the autostart dir on next login)

Let's discuss this in bug 576633.

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

Not sure everyone is aware of what follows (I risk to repeat someone...): 
In Ubuntu Jaunty (9.04) Beta, at /logout/, the user is asked if he wants to save open documents in gedit, OpenOffice etc. But at /shutdown/ or /restart/, he is not! 
Wheee... Somehow that's an improvement (because obviously there is work being done), and somehow the situation has gotten even worse than before: Now not only my experience with the (pre-) previous release makes me think that gnome protects my open documents, but even the /very same/ release induces this misapprehension! 

Unfortunately I cannot offer more help than testing whatever comes in Ubuntu Jaunty (Beta...). But this I'll do, promise!

(In reply to comment #173)
> Not sure everyone is aware of what follows (I risk to repeat someone...): 
> In Ubuntu Jaunty (9.04) Beta, at /logout/, the user is asked if he wants to
> save open documents in gedit, OpenOffice etc. But at /shutdown/ or /restart/,
> he is not! 

This is known and I'm working to fix this. (It's actually the last thing that prevents me from closing this bug...)

Finally fixed the shutdown/reboot issues. I committed everything and released a 2.26.0.90 test tarball so people can test things before 2.26.1.

So please test this tarball ASAP and file new bugs for issues you find with it (do not add comments to this bug, they will likely get lost)