GNOME Bugzilla – Bug 746754
Provide a way to disable auto save
Last modified: 2016-03-31 13:22:07 UTC
Starting with 3.16 boxes started to autosave and suspend / pause VMs not having an open window. I do however run VMs in the background for multiple cases where I access the VM either via network or let the VM run a long running task in the background. Being able to just close the window and let it running was one of the strengths of boxes .. i.e no clutter and can open it when needed. Can we at least have an option to disable that feature for selected boxes?
(In reply to drago01 from comment #0) > Starting with 3.16 boxes started to autosave and suspend / pause VMs not > having an open window. > > I do however run VMs in the background for multiple cases where I access the > VM either via network or let the VM run a long running task in the > background. > > Being able to just close the window and let it running was one of the > strengths of boxes .. i.e no clutter and can open it when needed. Why not just run them on separate windows on a specific workspace? > Can we at least have an option to disable that feature for selected boxes? We might want this anyway so keeping this open for now.
Running a box as a service provider might be a useful use case. You'd probably want to - autorun/resume it on Boxes launch - indicate it's running in the background and eating up resources without having an explicit window up. - close/suspend all/many of those boxes without having to open up a window one by one Needs design...
Quoting from the IRC conversation: <drago01> zeenix: one of my vms does nothing other then running a vpn client and a proxy server because it only runs on windows ... for this one I just open it log in close it and no longer care about it a window would be rather pointless <zeenix> drago01: yeah, that would be a good use case for the option i agree
There are similar design challenges here as with background apps in the OS itself. https://wiki.gnome.org/Design/Whiteboards/BackgroundApps
I also got bitten by this. One of my normal use cases for VM is to install an HTTP server for development (In reply to Jakub Steiner from comment #2) > - autorun/resume it on Boxes launch I do not think I would want to resume all my development VMs when starting boxes
(In reply to Paolo Borelli from comment #5) > I also got bitten by this. One of my normal use cases for VM is to install > an HTTP server for development For now, just run it in a separate window. A bit late to fix this for 3.16. > (In reply to Jakub Steiner from comment #2) > > - autorun/resume it on Boxes launch > > I do not think I would want to resume all my development VMs when starting > boxes I think he meant autorun/resume the ones you have selected as "Keep it on".
(In reply to Jakub Steiner from comment #4) > There are similar design challenges here as with background apps in the OS > itself. https://wiki.gnome.org/Design/Whiteboards/BackgroundApps Well it currently does background "express installs" without any of that fancy stuff and it did run things in the background just fine in < 3.16 so I don't think that this is that much of an issue really. > indicate it's running in the background and eating up resources without having an explicit window up. That's what some apps do using tray icons ... I am pretty sure we don't want that ... the other alternative would be a persistent notification which we just got rid of.
(In reply to drago01 from comment #7) > (In reply to Jakub Steiner from comment #4) > > > indicate it's running in the background and eating up resources without having an explicit window up. > > That's what some apps do using tray icons ... I am pretty sure we don't want > that ... the other alternative would be a persistent notification which we > just got rid of. I think the current distinction of colored vs grayscale thumbnails should do. Maybe we can have a simple field in the list view, once we have that (bug#733252).
*** Bug 751727 has been marked as a duplicate of this bug. ***
So are we going to get this fixed for 3.18?
(In reply to drago01 from comment #10) > So are we going to get this fixed for 3.18? I hope so! As usual, patches help speed things up. :)
(In reply to Zeeshan Ali (Khattak) from comment #11) > (In reply to drago01 from comment #10) > > So are we going to get this fixed for 3.18? > > I hope so! As usual, patches help speed things up. :) Well hard to do patches without knowing what the result should look like (UI etc.). Just add a setting somewhere in the VM options?
(In reply to drago01 from comment #12) > (In reply to Zeeshan Ali (Khattak) from comment #11) > > (In reply to drago01 from comment #10) > > > So are we going to get this fixed for 3.18? > > > > I hope so! As usual, patches help speed things up. :) > > Well hard to do patches without knowing what the result should look like (UI > etc.). You can implement the UI components as as start and get feedback on that first before making it work. > Just add a setting somewhere in the VM options? I'll go with a "Autosave" switch in "General" section.
So the intention for now is to add a per-VM suspend when in background option? Actually sounds useful to have it that way, as a user may want some VMs to always be suspended (or not) when in the background. Is there a better name than "auto-save", in order to indicate the VM will be suspended? E.g. "Auto-pause/save" or similar? Save on its own is likely to be seen as implying the same behaviour as saving a document - i.e. state saved but will still remain active.
(In reply to Stephen from comment #14) > So the intention for now is to add a per-VM suspend when in background > option? Actually sounds useful to have it that way, as a user may want some > VMs to always be suspended (or not) when in the background. Yeah. > Is there a better name than "auto-save", in order to indicate the VM will be > suspended? E.g. "Auto-pause/save" or similar? Save on its own is likely to > be seen as implying the same behaviour as saving a document - i.e. state > saved but will still remain active. Hmm.. maybe "Auto-Pause"?
(In reply to Zeeshan Ali (Khattak) from comment #15) > (In reply to Stephen from comment #14) > > So the intention for now is to add a per-VM suspend when in background > > option? Actually sounds useful to have it that way, as a user may want some > > VMs to always be suspended (or not) when in the background. > > Yeah. > > > Is there a better name than "auto-save", in order to indicate the VM will be > > suspended? E.g. "Auto-pause/save" or similar? Save on its own is likely to > > be seen as implying the same behaviour as saving a document - i.e. state > > saved but will still remain active. > > Hmm.. maybe "Auto-Pause"? How about "Keep running when window is closed" i.e no buzzword that the user has to guess or lookup ;)
(In reply to drago01 from comment #16) > (In reply to Zeeshan Ali (Khattak) from comment #15) > > (In reply to Stephen from comment #14) > > > So the intention for now is to add a per-VM suspend when in background > > > option? Actually sounds useful to have it that way, as a user may want some > > > VMs to always be suspended (or not) when in the background. > > > > Yeah. > > > > > Is there a better name than "auto-save", in order to indicate the VM will be > > > suspended? E.g. "Auto-pause/save" or similar? Save on its own is likely to > > > be seen as implying the same behaviour as saving a document - i.e. state > > > saved but will still remain active. > > > > Hmm.. maybe "Auto-Pause"? > > How about "Keep running when window is closed" i.e no buzzword that the user > has to guess or lookup ;) It's not just about being very obvious (which would be great indeed) but also about not making the UI look ugly. "Automatically Pause" would be fine I guess. We could also add a description below (or above) the option.
Just had an idea: How about an "Always on" option? This would imply Boxes never pauses VMs for which this is enabled, not even when quitting but rather pause and unpause for such a box is always manually done by user. Since selection-mode allows for pausing multiple boxes at once, it wont be an issue if user wants to pause many such boxes at once (e.g before quitting boxes). Alternatively, Boxes could still autopause on exit but start them on launch, i-e such boxes are always running when Boxes (app) is. What do you think?
I like the idea of opting in explicitely for "server" VMs and keep the default autopause for normal VMs
(In reply to Paolo Borelli from comment #19) > I like the idea of opting in explicitely for "server" VMs and keep the > default autopause for normal VMs You mean the first solution in comment#18 or the similar alternative in the second para?
I'd prefer the first paragraph. And I would definitely *not* want autoresume next time I run boxes :-)
Zeeshan, your option 2 wouldn't fix this bug, i.e. be able to close Boxes without pausing VMs.
(In reply to Stephen from comment #22) > Zeeshan, your option 2 wouldn't fix this bug, i.e. be able to close Boxes > without pausing VMs. We have been pausing boxes on exit since day 1 so I don't think this bug was about that (see comment#0) but yeah, I'm not so sure about option#2 either. :)
Created attachment 307171 [details] Screencast of wip solution Here is what I'm implementing right now.
So implemented the first solution in comment#18 on popular demand. :) See screenshot attached for how it looks. I hope this makes everyone happy now. :) commit: c627d229cca94de2d15e9bb510a22ab9db54c370 machine: Machine itself handles 'suspend_at_exit' Instead of having this as field of Machine that broker sets, let's make it a virtual property so subclasses can override it as per their need. commit: 324bdf2f88937ccf18c34da87487d35c065b1f7b libvirt-machine: Add a boolean 'run-in-bg' property This property dictates whether or not Boxes should automatically pause/save the machine or not. By default this is set to false. commit: 46ff257f6834c2657fa36198706e9e1a006d4744 libvirt-machine-props: UI for LibvirtMachine.run_in_bg Provide a switch in the 'System' tab of properties window to allow users to change the value of LibvirtMachine.run_in_bg.
Oh and thanks to jimmac for doing instant reviews of my screenshots and providing input. :) Forgot to give him credits in the commit log as usual so thought I should do so in here at least.