restore session by default

FYI there's an already-in-place mechanism in Glib.Application and therefore Granite.Application to fully save a state of an application and restore it later. This can be triggered by e.g. D-bus signal via the Glib.Application D-bus interfaces provided by any of our apps.

This is a very tempting shortcut at first glance. However, it might save the state a bit too fully - it serializes everything up to the the widget states and restores everything later, by which time the environment may have drastically changed and the saved state is no longer relevant.

It might prove useful, but has to be thoroughly investigated and used with care.

If we have a legitimate reason to exclude Switchboard, we should try to distinguish what exactly the difference between it and other apps is. For example, is it utility vs. content creation? No, because Music isn't content creation and we save its state. Is it system vs. app? Maybe, but where does that line exist?

I think changing a setting, then hitting close, then going back to change its setting again in a bit would work well with Switchboard saving its state. There's a big, obvious home button on the top-left (the most prominent location in an app), so it's not like a user will get lost.

I don't see why we wouldn't want to save the state of switchboard. Is there a solid reason why not?

The app should restore:
 * Window Geometry
 * Window State
 * Window Position
 * Window Monitor
 * Panels Geometry

I've ticketed this upstream at http://redmine.yorba.org/issues/6325

IMO, Switchboard shouldn't restore session. In most cases one would finish a task, and then close Switchboard. But upon opening Switchboard again, the person might not want to do what the original task. For example:

- User opens Switchboard
- User links a new account to Online Accounts
- User closes Switchboard
- User finds a cool wallpaper online
- User opens Switchboard intending to change the wallpaper
- Switchboard opens to the Online Accounts plug.

This especially becomes a strange behaviour as some plugs are rarely used or set and forget: Keyboard, Mouse, Network, About. It would be better UX to not assume what the user would want to do upon launch and let him/her choose, it's really easy to find out where everything is anyway.

There should be an option to disable this. Me and my husband have been testing Freya for a few days now and it has seriously been irritating us to death that when we open Pantheon-Files it goes to where we last was instead of were its supposed to, the home folder. I came here thinking it was a bug and find that for some strange reason its ACTUALLY and intended feature. Come to mention a few other apps have been getting on my nerves because they open the previous session. When I close the app, I'm done with it. PERIOD. When I open it again, I and everyone I've ever known expects to start a new session. NOT opening, have to close or navigate away from the previous session and then trying to get to where I expect my session to originally have started at. In this case my home folder. Which is were Pantheon-Files SHOULD go when I open a new session. If for some bizarre reason you Devs want it to do that, thats perfectly fine, but give us the option to fix it.

shashing93: In Files, you can disable tab restoring by editing the dconf settings "org.pantheon.files.preferences.restore-tabs" using dconf-editor or otherwise.

A possible compromise on this, which would not involve editing the settings, would be to have Files always open the Home Folder plus whatever other folders were last open in separate tabs. Perhaps another bug (wishlist) could be opened if this was wanted?

+1 @Jeremy "Open home folder plus restore old session in separate tabs"