GNOME Bugzilla – Bug 301949
should not write the session when changing automatic session saving option
Last modified: 2021-06-14 18:22:50 UTC
Please describe the problem: gnome-session currently saves gnome-session-properties which presents a major problem for users who wish not to save their session at every logout. One cannot easily turn off automatic session saving without also saving the session-properties dialog. Steps to reproduce: 1. Set up a desktop as desired (with automatic session saving on). 2. Log out/Log in to save the session. 3. Turn off automatic session saving with gnome-session-properties. 4. Close gnome-session-properties and log out/log in. Actual results: gnome-session-properties now starts with every log in Expected results: Usually, one does not want gnome-session-properties to be saved in the session. By saving it in the session it becomes impossible [for the novice user] to set up a permanent clean desktop with no programs starting (other than the panel + nautilus). One always ends up with gnome-session-properties starting, or session saving turned on. This ends up making gnome look very unprofessional, and could be easily fixed by having gnome-session-properties not be managed by gnome-session. Does this happen every time? Other information:
Thanks for your bug. The issue is not clear. Why not simply closing the window before saving the session?
That's exactly the point, I can't, because the window is the only way for me to save the session (although it is not clearly marked as such). There are only two user visible (non-commandline) ways to save one's session. One can logout while "Automatically Save Session on Logout" is set to true, alternately one can unselect the "Automatically Save Session on Logout" option in the gnome-session-properties. I don't want the first option, which leaves me only the second which remembers that gnome-session-properties was running and starts it every time. Whatever dialog (whether clearly marked or not) one uses to save a session should not be included in the session to avoid this problem.
This window is not useful to store the session, why can't you close it? Just change the option, close the session and store your session ...
Unless I have missed something there is no way for me to store the session, because there is no menu option to save session. So once I change the option so that "Automatically Save Session on Logout" is off then how can I save the session without turning to the command line (I know how to do this from the command line but the average user will not). By Steps: 1. Set up session as one likes it with "Automatically Save Session on Logout" 2. Go to turn off Automatic Session Saving 3. When "Automatically Save Session on Logout" is unselected session is immediately saved and includes gnome-session-properties 4. Close gnome-session-properties 5. There is now no way to save ones session (Correct me if I am wrong on this), and gnome-session-properties is included in the session.
3. why unselecting the option should store the session? 5. select the "Ask on logout" option, the dialog will have the option and you just have to click when you want to store the current session ...
I agree on 3, I don't understand why it is doing that either. It isn't clearly marked as such but it seems to be doing so (for the record I am not certain that it is unselecting the option which saves the session it could be closing the gnome-session-properties, but I believe it is the checkbox which does it). There should probably be a button or menu entry that saves the session (I think fedora has a menu entry but Gentoo doesn't [I assume Gentoo is mostly stock Gnome]). I would suggest adding a button to gnome-session which says "Close and save session" or some such, which would run gnome-session-save after exiting. The problem with 5 is that I don't want to be asked every time. I know what I want my session to look like. I want to set it to that one time and never be bothered with managing it again, there is currently no way of doing that without knowing the magic gnome-session-save incantation, or by manually editing the .gnome2/session file.
3 seems to be the bug, there should no be any save here. Could you join your ~/.gnome2/session before clicking on the option and after? for 5 put the option, use it once to store the session and turn the option ... the session will not change and the question is not asked, what is exactly your issue?
Created attachment 50026 [details] Session Before Opening gnome-properties
Created attachment 50027 [details] Session after opening gnome-session-properties and unselecting "Automatically Save Changes to Session" The diff is ~/.gnome2:> diff session session.debug 54,59c54 < 8,id=117f000001000112283486400000103630019 < 8,Program=gnome-session-properties < 8,CurrentDirectory=/home/escott/.gnome2 < 8,CloneCommand=gnome-session-properties < 8,RestartCommand=gnome-session-properties --sm-client-id 117f000001000112283486400000103630019 --screen 0 < num_clients=9 --- > num_clients=8 and it is only added by unselecting "Automatically Save Changes" which I believe must be selected prior to starting gnome-session-properties. And Yes removing this behavior should fix the problem, although requiring a more roundabout way than I had hoped.
the bug is that changing this option should not change the session
I can't reproduce this. Can you still reproduce? (and I see no reason why this would happen...)
(Couldn't reproduce with 2.16, btw)
*** Bug 351464 has been marked as a duplicate of this bug. ***
https://launchpad.net/ubuntu/+source/gnome-session/+bug/34321/comments/7 I still can reproduce the bug on Edgy with latest updates: To reproduce: 1. Go to System/Sessions/ and select Automatically save changes to session. 2. Open an application (e.g. gedit) 3. log out and log in result: as expected gedit is opened automatically 4. Go to System/Sessions/ and unselect Automatically save changes to session. 5. log out and log in result: nautilus and the Sessions dialogue and gedit are opened automatically despite of the fact that we deselected "Automatically save changes..." Best regards Christian
Can Reproduce gnome-session --version 2.16.2 gentoo
https://bugs.launchpad.net/gnome-session/+bug/34321/comments/11 This bug is still present. I just installed Ubuntu 7.04 on my intel386 laptop to test if this bug is still present with Gnome 2.18.1 and Gnome-session 2.18.0. There is a slight change in the misbehavior, compared to former misbehavior: Now the session dialog box is not saved anymore at the moment when the "Automatically save changes to the session" is unselected. However the session is still saved at that moment. To produce this bug I did the following: 1. Boot into Gnome 2. Open Nautilus 3. Select "Automatically save changes to the session" in the System/Sessions/Session Options dialog. 4. Log out and log in again result: as expected Nautilus is opened after login in. 5. Open in addition the Gedit Text-editor. 6. unselect "Automatically save changes to the session" in the System/Sessions/Session Options dialog. 7. Log out and log in again result: Nautilus and the Text-editor are opened exactly as they have been at the moment at which I have unselected the "Automatically save changes to the session" expected results: getting a plain standard desktop after the login (without open gnome-application). It seems like at the exact moment when unselecting the save-session option the session is saved for a last time and this session is reestablished after each log-in. Instead either the file ~/.gnome2/session should be deleted at the moment where the option is unselected or the file ~/.gnome2/session should be replace by the default one (which delivers a plain desktop)??? However, since now there is the option "Save the current session" in the System/Session/Session Options dialog it is easy to get back to the default desktop. In my case it was sufficient to close Nautilus and Gedit and to click on "Save the current session". Thanks a lot to the developers to add this very useful option.
*** Bug 581819 has been marked as a duplicate of this bug. ***
*** Bug 586299 has been marked as a duplicate of this bug. ***
The original bug report's title is incorrect, and its directions are a little confusing. It should be "should delete the saved session when removing automatic session saving option" I don't really know how to navigate code yet. I happened across an archive of gnome-session on the net. Looking at that code, it looks like the last saved session is deleted when creating a new saved session. I suspect that is the only place that session data is deleted, so when session saving is turned off, the last saved session never gets deleted. Vincent: Are you still having trouble reproducing this bug? BTW, here is the latest workaround: rm -R ~/.config/gnome-session/saved-session It doesn't get rid of all saved session data, but it cleans up what programs are started up.
I added a rudimentary patch for this at Bug 581819 (It's uggly... you've been warned! :) ) It does the same thing as your command but when you uncheck the automatic save box.
Oskar: I saw your patch. I was thinking that it would be better to make a call to gsm_session_save in gsm-session-save.c. Maybe something like gsm_session_save(NULL,NULL). I really don't know what those NULLs will do though. And, there is a FIXME in gsm_session_save that might prevent that from working. In fact, that FIXME may need to be fixed before a patch can be implemented in the way that I'm thinking. Ultimately, I'm having trouble understanding what gsm_session_save is doing with the hash tables. Oskar, as I think this through, your patch seems fine as a temporary fix. It just needs to use gsm_util_get_saved_session_dir () instead of hardcoding the path, and maybe a FIXME comment explaining that it orphans a few session save files. Then, whoever fixes gsm_session_save can implement a proper fix for this bug too. +1 for Oskar's patch in the meantime! All my comments are based on code that I found here: http://gnome-session.sourcearchive.com/documentation/2.26.0svn20090408/gsm-session-save_8c-source.html
FYI, I've fixed this bug downstream, though not in the way that I originally supported. I just added a check against the gconf setting before loading the saved session. I haven't posted a patch since I'm quite new to this, and I don't know how to create patches. The fix is so simple that I could just paste the lines, but I figure that I need to learn about the patching anyway.
Created attachment 144138 [details] [review] fix autostarting of apps after the option has been disabled I just added a check which checks if autosave session is enabled. If it isn't, all apps in ~/.config/gnome-session/session-save or whatever it is are blocked. I also refactored a bit to expose the appropriate function which performs said check.
OK. I've updated to Ubuntu Karmic Beta/Gnome 2.28.0 and manually changed the gnome-session source from your diff and it works all fine for me. :D ( I couldn't figure out how to produce an updated diff for it though... :P -? ) You leave the saved-session directory untouched so the last session is still remembered when autosave session is disabled. Test: Enable autosave. Open gedit and nothing else. Log out and then in again. Disable autosave. Close all windows and once more log out/in. One of the files in the saved-session directory (the last one in my computer) is the gedit "memmory". Double click (and boldly ignore any warnings!) to have it magically reappear! :) I don't know if this could lead to any problems.
@Oskar, I was actually half way through coding your patch when I decided to go this route. I was browsing through the code and looking for examples on how to code things and I noticed that that folder is only accessed for loading and saving in a single spot. (I'm pretty sure I came to that conclusion on 2.26 though) So when I found the loading was in a single spot and the appropriate check already had a function implementing it, I felt that it was best to do it the way I did it. The change is basically a single line. Anyway, thanks for the inspiration! @Maintainer I felt that having a check as I did is functionally equivalent to deleting the folder. When I deleted the folder as a work around, it stayed deleted AFAIK. As long as that is true, then I am correct. I did notice that there is a new button which is somewhat odd. It looks like it may be an odd and more complicated method to work around this bug. I suspect that there is more complicated stuff going on than I realize. O well! I'm learning so feedback welcome. Also, I have applied this fix to the 2.28 code in the alpha of Ubuntu. I will update it when Ubuntu gets released.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.