GNOME Bugzilla – Bug 594802
(prototype) Restore previously open applications automatically on shell startup
Last modified: 2013-05-24 15:50:06 UTC
Just a bit of an experiment to automatically re-launch applications.
Created attachment 142940 [details] [review] [ShellAppMonitor] Expose shell_app_monitor_get_previously_running Keep track of the application ids per context, instead of just AppUsage which doesn't have the info we need. Expose it publicly.
Created attachment 142941 [details] [review] (prototype) Restore previously open applications automatically on shell startup Hook into shell startup, and launch in series the applications which were open previously. There is a significant amount more work to do to make this more productized. * Need to actually hook into startup notification if possible - Depends on startup-notification association with .desktop files * Have a story for what application authors should do to restore multiple windows (XSMP? Manually? Get support into GTK+ for state saving?)
Hey, great! I was just starting to wonder again about how we could achieve that terrible goal... So if I understand correctly, your current patches track applications per context, but only restore the defa
Created attachment 142942 [details] [review] [ShellAppMonitor] Expose shell_app_monitor_get_previously_running Keep track of the application ids per context, instead of just AppUsage which doesn't have the info we need. Expose it publicly.
(continued...) only restore the default one? I guess it will be quite hard to restore the right window(s) on the right workspace(s). In my fool designs, we would be able to restore window apps when we want on the context we want, which would mean: - apps need to restore several windows - apps need to be able to save a state and restore another one without losing the other, waiting for the corresponding context to be restored later - we thus need to restore the app on the right workspace, and to tell it what context (or session ID) it should use Given that session saving does not look close to being fixed, defining One Best Way to handle it, I'm not sure how we can move towards this goal. Do you have plans where I could help? Contexts support in the Shell itself (linked with Zeitgeist) won't solve the problem alone...
Created attachment 142943 [details] [review] (prototype) Restore previously open applications automatically on shell startup Hook into shell startup, and launch in series the applications which were open previously. There is a significant amount more work to do to make this more productized. * Need to actually hook into startup notification if possible - Depends on startup-notification association with .desktop files * Have a story for what application authors should do to restore multiple windows (XSMP? Manually? Get support into GTK+ for state saving?)
Well...the problem I am most interested in solving is the software update -> logout/reboot issue (and suspend not always working in Linux). This one is closest to what XSMP is trying to solve, and maybe with the re-added support in GNOME Panel we should use it if available. But I do think that applications shouldn't have to jump through the XSMP hoop unnecessarily. Restoring windows on workspaces in this scenario should be straightforward relatively.
Also for this patch we should, once we're done restoring applications, exit the overview (if the user hasn't taken any action) and have focused whichever app was focused before.
Owen notes that to do this for the browser sanely, we need to make sure the browser is blocked until network connection is active. Possible thoughts on that: * Have a key in the .desktop file which says whether an app relies on the network, if so just block (with some timeout) until we have network * Patch the app UI to start up but specifically handle no network
I have some concerns about this on basic grounds. Various reasons why the user might be logging in: 1. First time logging in 2. They previously decided they were "done", and shut down the machine rather than suspending. 3. Everything got really messy and confusing and they logged out or rebooted to get back to a clean state. 4. Crash, power loss, etc. 5. Some sort of automatied reboot process on 1. obviously doesn't matter For 2. I'll argue that restarting apps is a bad thing - we're taking the user back to a messy and stale state rather than a simple state (clean desktop) For 3. restarting apps is a bad thing. For 4. and 5. we want the user to get back *exactly* where they were, ideally. but I'll argue that getting 80% of the way there isn't useful. You've put the user back into a complex state that they don't understand. And just restarting the apps that were running before doesn't get you anywhere close to that 80%. Apps that aren't "document based" *should* be keeping persistent state and returning to it when run. But a lot of our apps don't do that. And a large other set of apps *should not* do that. It would be the wrong behavior for ooimpress, etc. I think it's more immediate to focus on: A) Making sure that the apps that the user wants to start are in the app well, and they never have to browse for them. B) Making apps indididually restore state as appropriate. If it's really easy for the user to get from "Frequent App State A" to "Frequent App State B", then it's also easy from 0 to "Frequent App State A".
I've come to the following idea several times on the Internet (maybe this approach is more usable and also implementable): Make profiles for workspaces. They each should contain different set of applets on-screen and pre-open applications/documents/tabs (and for hardcore users event different set of files and links on a desktop). So that you can create a gaming workspace, news-reading, programming workspace, or open several of document-working workspaces. (When you open workspace, you choose which profile it should use) Make this profiles easily forkable :) and enable saving current state of a workspace as a profile. Hardcore users scenario (with different set of files on a Desktop): To make it less cumbersome let user himself select/create a Desktop folder for each profile. (it still needs a lot of thought at least to be sure that user won't delete "the second disk C:" :) )
(bugzilla spam: populating the new "extensions" component with bugs discussing features that are not part of the core spec, but could be implemented externally once the extension system is done.)
Comment on attachment 142942 [details] [review] [ShellAppMonitor] Expose shell_app_monitor_get_previously_running Marking patch needs-work since it would clearly not apply to the current code.
Comment on attachment 142943 [details] [review] (prototype) Restore previously open applications automatically on shell startup Marking patch needs-work since it would clearly not apply to the current code.
I'll tentatively close this - the extensions component is used for bugs against gnome-shell-extensions nowadays, and I doubt potential extension authors will browse bugzilla for ideas. Also it doesn't look like anyone has put any work into this in more than three years ... Colin, feel free to reopen if you intend to pick this up (and run by the design team of course ;-) )