I've selected option to save session after logout, then I disable that option but XFCE still starts application after login I solved it by deleting entries in "$HOME/.cache/sessions" but I think that could be run automatically
No, unchecking that box doesn't delete sessions, it just doesn't save any new ones. It behaves as expected.
Ok, but then add button which deletes old one, or the other concept
Reassign to xfce-bugs@xfce.org.
I think an option 'don't load saved session on startup' in the startup settings would be nice.
Created attachment 3587 Proposed patch The following patch adds a "clear saved sessions" on the "Session" tab in xfce4-session-settings, which deletes "$XDG_CACHE_HOME/sessions/xfce4-session-*". I don't know if it's worth/safe to delete more (e.g. the xfwm4 or thunar states stored in there). Also, feel free to move the button at a more suitable place. :p I tested it on Xfce 4.8 (I don't currently have master running), and it worked fine here.
Mmmh (just my 2 cents), it might look better if the button is placed near the "save session" button. It seems that removing "<property name="pack_type">end</property>" from my patch does that.
The current patch looks ok. I have two suggestions though: 1) I think the button should only be sensitive when there is something to delete. A check when creating the dialog is enough, no need to monitor. When finishing the cache cleaning, we would just set the state to insensitive. It's not a big deal but it makes sense IMO. 2) The description in the confirmation dialog could be improved by saying what could potentially be lost. I don't know everything we can store in session files, but at least saved applications. Re deleting Thunar and Xfwm4 session files, it makes sense IMO.
Sorry, form accidentally validated... So, I'm adding Nick and Jannis as CC to get feedback on thunar and xfwm4 files. And one last point, it would be great if you added the bug number at the end of the patch summary like '(bug #xxxx).', that way I don't even have to do that (or to forget to do it) ;) And finally, THANKS!
When you start a new session the thunar xfwm4 and other session files are invalid because the app is assigned a new client-id, so you can safely delete those too.
Officially xfce4-session does not depend on gio and because session files are always local, I'd say a g_dir_open; walk; g_unlink; will do.
Created attachment 3590 Proposed patch (2) Thanks for the feedback! (In reply to comment #7) > The current patch looks ok. > > I have two suggestions though: > > 1) I think the button should only be sensitive when there is something to > delete. A check when creating the dialog is enough, no need to monitor. When > finishing the cache cleaning, we would just set the state to insensitive. It's > not a big deal but it makes sense IMO. > > 2) The description in the confirmation dialog could be improved by saying what > could potentially be lost. I don't know everything we can store in session > files, but at least saved applications. > > Re deleting Thunar and Xfwm4 session files, it makes sense IMO. 1) I think it's more annoying than expected, because the "save session" button can write items in there, and restarting Thunar/xfwm4 also (and in this case, if the button stays greyed out it's misleading). 2) I tried to improve that a bit, feel free to change it. (In reply to comment #9) > When you start a new session the thunar xfwm4 and other session files are > invalid because the app is assigned a new client-id, so you can safely delete > those too. I included a check to delete them as well. However, when thunar/xfwm4 starts, a state file is written for them with their *current* client-id... Is it really safe to remove that? (In reply to comment #10) > Officially xfce4-session does not depend on gio and because session files are > always local, I'd say a g_dir_open; walk; g_unlink; will do. Done. It doesn't delete everything though (I'm thinking about people using several desktop environments who won't be happy if everything is deleted, so I only delete "xfce4-session-*", "Thunar-*", "xfwm4-*"...).
(In reply to comment #11) > Created attachment 3590 > Proposed patch (2) > > Thanks for the feedback! Thanks for the quick follow up! > > (In reply to comment #7) > > The current patch looks ok. > > > > I have two suggestions though: > > > > 1) I think the button should only be sensitive when there is something to > > delete. A check when creating the dialog is enough, no need to monitor. When > > finishing the cache cleaning, we would just set the state to insensitive. It's > > not a big deal but it makes sense IMO. > > > > 2) The description in the confirmation dialog could be improved by saying what > > could potentially be lost. I don't know everything we can store in session > > files, but at least saved applications. > > > > Re deleting Thunar and Xfwm4 session files, it makes sense IMO. > > 1) I think it's more annoying than expected, because the "save session" button > can write items in there, and restarting Thunar/xfwm4 also (and in this case, > if the button stays greyed out it's misleading). Good point which I hadn't considered, let's forget this then! > > 2) I tried to improve that a bit, feel free to change it. Looks fine to me. > > (In reply to comment #9) > > When you start a new session the thunar xfwm4 and other session files are > > invalid because the app is assigned a new client-id, so you can safely delete > > those too. > > I included a check to delete them as well. However, when thunar/xfwm4 starts, a > state file is written for them with their *current* client-id... Is it really > safe to remove that? > > (In reply to comment #10) > > Officially xfce4-session does not depend on gio and because session files are > > always local, I'd say a g_dir_open; walk; g_unlink; will do. > > Done. It doesn't delete everything though (I'm thinking about people using > several desktop environments who won't be happy if everything is deleted, so I > only delete "xfce4-session-*", "Thunar-*", "xfwm4-*"...). I just have one itch with the new patch, the g_critical and g_warning: I know this shouldn't happen in most cases but I don't like throwing errors to the console and filling logs which are never read. Shouldn't we warn the user with a dialog that clearing the session failed (like in the first version of your patch)?
(In reply to comment #12) > > I just have one itch with the new patch, the g_critical and g_warning: I know > this shouldn't happen in most cases but I don't like throwing errors to the > console and filling logs which are never read. Shouldn't we warn the user with > a dialog that clearing the session failed (like in the first version of your > patch)? Indeed, I'm not especially happy with that. My first patch would have displayed a warning dialog for each failure, which is too much. Then, I wanted to display one single warning if something went wrong, e.g. "Unable to clear some cache item, you might have to do it manually.", but I'm thinking it's pretty useless and meaningless for an average user. That's why I chose to "hide" that in .xsession-errors. Ideas are welcome... ;-)
I just pushed this to git master with two small follow up patches. Thanks a lot for your contribution, that's one release goal fixed!
I just realize re-reading your last message that I picked the "useless" solution for user feedback ^^ I don't know what we can improve there, but I think some feedback is better here. It shouldn't happen that often thought, so it's ok IMO if the warning is not crystal clear. We will see if we can improve this.