After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746754 - Provide a way to disable auto save
Provide a way to disable auto save
Status: RESOLVED FIXED
Product: gnome-boxes
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: 3.22
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
: 751727 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-25 16:05 UTC by drago01
Modified: 2016-03-31 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screencast of wip solution (311.72 KB, video/webm)
2015-07-09 18:48 UTC, Zeeshan Ali
Details

Description drago01 2015-03-25 16:05:04 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?
Comment 1 Zeeshan Ali 2015-03-25 16:21:07 UTC
(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.
Comment 2 Jakub Steiner 2015-03-25 16:45:11 UTC
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...
Comment 3 drago01 2015-03-25 16:47:21 UTC
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
Comment 4 Jakub Steiner 2015-03-25 16:48:54 UTC
There are similar design challenges here as with background apps in the OS itself. https://wiki.gnome.org/Design/Whiteboards/BackgroundApps
Comment 5 Paolo Borelli 2015-03-25 16:59:38 UTC
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
Comment 6 Zeeshan Ali 2015-03-25 17:05:46 UTC
(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".
Comment 7 drago01 2015-03-25 18:28:44 UTC
(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.
Comment 8 Zeeshan Ali 2015-03-25 18:33:32 UTC
(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).
Comment 9 Zeeshan Ali 2015-06-30 15:37:18 UTC
*** Bug 751727 has been marked as a duplicate of this bug. ***
Comment 10 drago01 2015-06-30 15:41:06 UTC
So are we going to get this fixed for 3.18?
Comment 11 Zeeshan Ali 2015-06-30 15:44:29 UTC
(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. :)
Comment 12 drago01 2015-06-30 15:51:53 UTC
(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?
Comment 13 Zeeshan Ali 2015-06-30 16:51:33 UTC
(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.
Comment 14 Stephen 2015-06-30 17:32:59 UTC
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.
Comment 15 Zeeshan Ali 2015-06-30 18:01:53 UTC
(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"?
Comment 16 drago01 2015-06-30 18:17:13 UTC
(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 ;)
Comment 17 Zeeshan Ali 2015-06-30 18:31:42 UTC
(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.
Comment 18 Zeeshan Ali 2015-07-08 17:34:08 UTC
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?
Comment 19 Paolo Borelli 2015-07-08 18:00:23 UTC
I like the idea of opting in explicitely for "server" VMs and keep the default autopause for normal VMs
Comment 20 Zeeshan Ali 2015-07-08 18:03:42 UTC
(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?
Comment 21 Paolo Borelli 2015-07-08 19:35:37 UTC
I'd prefer the first paragraph. And I would definitely *not* want autoresume next time I run boxes :-)
Comment 22 Stephen 2015-07-09 05:18:46 UTC
Zeeshan, your option 2 wouldn't fix this bug, i.e. be able to close Boxes without pausing VMs.
Comment 23 Zeeshan Ali 2015-07-09 11:34:35 UTC
(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. :)
Comment 24 Zeeshan Ali 2015-07-09 18:48:49 UTC
Created attachment 307171 [details]
Screencast of wip solution

Here is what I'm implementing right now.
Comment 25 Zeeshan Ali 2015-07-09 19:30:56 UTC
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.
Comment 26 Zeeshan Ali 2015-07-09 19:33:58 UTC
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.