GNOME Bugzilla – Bug 781469
RFE: Move the "Delete" option further from the "Clone" option
Last modified: 2018-01-11 10:53:06 UTC
Accidentally clicking on "Clone" instead of "Delete" may lead the user to wait for several minutes till the process of cloning the VM is finished. Another option would be to confirm whether the user really want to clone the VM and let they Cancel the operation before it starts. Even another option would be to allow cancelling the "Clone" operation after it started.
For now it could be a solution. As an extended goal for this bug, I would suggest making the clone operations cancellable as soon as they start (allowing the deletion of these machines at any time).
Is a Dialog asking if the user want to continue with the cloning or deleting out of question? I think it would be a nice to have it but if the idea of the gnome-boxes team is to have as less mouse clicks as it could have than it wouln't be nice.
No, we don't want to create confirmation dialogs. The interactions should be seamless and easily reversible instead.
Created attachment 355629 [details] [review] Display message This issue depends on fixing the bug #781468 otherwise it will clone the machines many times so don't run it without fixing the bug #781468 first. I'm in doubt if I should send both patchs here or a patch for each issue (like I did). This patch follow the idea from the delete function where the user will be able to undo the process (before it starts). Just let me know if you are looking for another approach!
Thiago, Firstly, thanks for the patch! (In reply to Thiago Mendes from comment #4) > Created attachment 355629 [details] [review] [review] > Display message > > This issue depends on fixing the bug #781468 otherwise it will clone the > machines many times so don't run it without fixing the bug #781468 first. > > I'm in doubt if I should send both patchs here or a patch for each issue > (like I did). > > This patch follow the idea from the delete function where the user will be > able to undo the process (before it starts). > > Just let me know if you are looking for another approach! So, I'm really not a big fond of this approach. The user should be able to cancel the cloning process at *any* time, not only during a short time span before the cloning actually starts. For now I'd just move the button away (so, at least we have something) and then work on a proper solution for cancelling the operation. Are you, somehow, familiar with https://developer.gnome.org/gio/stable/GCancellable.html ? That's pretty much what should be used for the proper fix mentioned both in comment 1 and comment 2.
(In reply to Fabiano Fidêncio from comment #5) > Thiago, > > Firstly, thanks for the patch! > > (In reply to Thiago Mendes from comment #4) > > Created attachment 355629 [details] [review] [review] [review] > > Display message > > > > This issue depends on fixing the bug #781468 otherwise it will clone the > > machines many times so don't run it without fixing the bug #781468 first. > > > > I'm in doubt if I should send both patchs here or a patch for each issue > > (like I did). > > > > This patch follow the idea from the delete function where the user will be > > able to undo the process (before it starts). > > > > Just let me know if you are looking for another approach! > > So, I'm really not a big fond of this approach. The user should be able to > cancel the cloning process at *any* time, not only during a short time span > before the cloning actually starts. > > For now I'd just move the button away (so, at least we have something) and > then work on a proper solution for cancelling the operation. > > Are you, somehow, familiar with > https://developer.gnome.org/gio/stable/GCancellable.html ? That's pretty > much what should be used for the proper fix mentioned both in comment 1 and > comment 2. I'm also not a big fan. I was just following the same approach gnome-boxes has for the delete function (no popup) Thanks for the link. I'm not familiar with it. I came from the embedded system world so no glib, no gtk or vala before. That's why I came for the newcomers :) I'm gonna read about it but as far as I see here gnome-boxes calls a exec function to execute an external binary (qemu-img) and this one takes a long time to run. Would I be able to cancel it after start with the GCancellable? Anyway I'm gonna read about it.
(In reply to Thiago Mendes from comment #6) > (In reply to Fabiano Fidêncio from comment #5) > > Thiago, > > > > Firstly, thanks for the patch! > > > > (In reply to Thiago Mendes from comment #4) > > > Created attachment 355629 [details] [review] [review] [review] [review] > > > Display message > > > > > > This issue depends on fixing the bug #781468 otherwise it will clone the > > > machines many times so don't run it without fixing the bug #781468 first. > > > > > > I'm in doubt if I should send both patchs here or a patch for each issue > > > (like I did). > > > > > > This patch follow the idea from the delete function where the user will be > > > able to undo the process (before it starts). > > > > > > Just let me know if you are looking for another approach! > > > > So, I'm really not a big fond of this approach. The user should be able to > > cancel the cloning process at *any* time, not only during a short time span > > before the cloning actually starts. > > > > For now I'd just move the button away (so, at least we have something) and > > then work on a proper solution for cancelling the operation. > > > > Are you, somehow, familiar with > > https://developer.gnome.org/gio/stable/GCancellable.html ? That's pretty > > much what should be used for the proper fix mentioned both in comment 1 and > > comment 2. > > I'm also not a big fan. I was just following the same approach gnome-boxes > has for the delete function (no popup) > > Thanks for the link. I'm not familiar with it. I came from the embedded > system world so no glib, no gtk or vala before. That's why I came for the > newcomers :) > > I'm gonna read about it but as far as I see here gnome-boxes calls a exec > function to execute an external binary (qemu-img) and this one takes a long > time to run. Would I be able to cancel it after start with the GCancellable? > Anyway I'm gonna read about it. Aha. If the binary is called then maybe we're doomed here. :-) As we've discussed in Boxes channel is worth to check whether libvirt/libvirt-glib provide some API for doing what we need (I don't think so, otherwise virt-manager would be taking advantage of it ... but seems they do have the same issue as Boxes).
(In reply to Fabiano Fidêncio from comment #7) > (In reply to Thiago Mendes from comment #6) > > (In reply to Fabiano Fidêncio from comment #5) > > > Thiago, > > > > > > Firstly, thanks for the patch! > > > > > > (In reply to Thiago Mendes from comment #4) > > > > Created attachment 355629 [details] [review] [review] [review] [review] [review] > > > > Display message > > > > > > > > This issue depends on fixing the bug #781468 otherwise it will clone the > > > > machines many times so don't run it without fixing the bug #781468 first. > > > > > > > > I'm in doubt if I should send both patchs here or a patch for each issue > > > > (like I did). > > > > > > > > This patch follow the idea from the delete function where the user will be > > > > able to undo the process (before it starts). > > > > > > > > Just let me know if you are looking for another approach! > > > > > > So, I'm really not a big fond of this approach. The user should be able to > > > cancel the cloning process at *any* time, not only during a short time span > > > before the cloning actually starts. > > > > > > For now I'd just move the button away (so, at least we have something) and > > > then work on a proper solution for cancelling the operation. > > > > > > Are you, somehow, familiar with > > > https://developer.gnome.org/gio/stable/GCancellable.html ? That's pretty > > > much what should be used for the proper fix mentioned both in comment 1 and > > > comment 2. > > > > I'm also not a big fan. I was just following the same approach gnome-boxes > > has for the delete function (no popup) > > > > Thanks for the link. I'm not familiar with it. I came from the embedded > > system world so no glib, no gtk or vala before. That's why I came for the > > newcomers :) > > > > I'm gonna read about it but as far as I see here gnome-boxes calls a exec > > function to execute an external binary (qemu-img) and this one takes a long > > time to run. Would I be able to cancel it after start with the GCancellable? > > Anyway I'm gonna read about it. > > Aha. If the binary is called then maybe we're doomed here. :-) > > As we've discussed in Boxes channel is worth to check whether > libvirt/libvirt-glib provide some API for doing what we need (I don't think > so, otherwise virt-manager would be taking advantage of it ... but seems > they do have the same issue as Boxes). Just for the record, crobinso said on #boxes channel: "virt-manager uses the pool CreateXMLFrom API for cloning, which will use qemu-img in some cases". I didn't check Boxes code at all, but maybe that's what we're doing (maybe we're just calling qemu-img directly), not exactly sure. If we really have to rely on qemu-img, then the cancellable approach may start to get at least a little bit more complicated.
(In reply to Fabiano Fidêncio from comment #8) > > Just for the record, crobinso said on #boxes channel: "virt-manager uses the > pool CreateXMLFrom API for cloning, which will use qemu-img in some cases". Yes, libvirt doesn't have an api for that. > I didn't check Boxes code at all, but maybe that's what we're doing (maybe > we're just calling qemu-img directly), not exactly sure. We are pretty much doing what crobinso said, you can see in [0] that we get the XML from a domain and we create a VM from this XML. [0] https://git.gnome.org/browse/gnome-boxes/tree/src/libvirt-machine.vala#n684
This is definitely no longer a #newcomers bug. :) The solution we want is something in the lines of the EXPERIMENTAL patch below. We still need the proper API. This way (with the patch), you are able to Delete a machine at anytime BUT when the deleting in fact happens, it is a blocking (could even cause the UI to freeze).
Created attachment 355744 [details] [review] libvirt-machine: Allow the cancellation of clones
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/138.