GNOME Bugzilla – Bug 668792
Handle errors better
Last modified: 2016-03-31 13:59:38 UTC
I was trying out Boxes on F16 today and tried installing a new box from a rawhide nightly. I selected the iso from disk and clicked continue and then the interface stopped responding at "Analyzing installer media". Looking in .xsession-errors I see: Boxes-WARNING **: wizard.vala:136: Failed to create domain: internal error Process exited while reading console log output: qemu-system-x86_64: -spice port=5900,addr=127.0.0.1,disable-ticketing: there is no option group "spice" spice is not supported by this qemu build. We should probably detect such errors earlier and do a better job of handling errors during the analysis step.
If the system isn't capable of running Boxes you should use a sad computer or equivalent.
(In reply to comment #1) > If the system isn't capable of running Boxes you should use a sad computer or > equivalent. A bunch of sad boxes would be more appropriate, no? :)
Created attachment 206530 [details] [review] More generic notification bar Now its also possible to display errors through notification bar and new types of messages are now trivial to add. It is also now visible in all UI states except for 'DISPLAY'. Do we want it there? Not sure if this is an issue for us but the colors of Gtk.InfoBar remain always the same regardless of type of message. While we do set the appropriate message type on the Gtk.InfoBar, we set our own style on it as well. So if we need this, we need to figure how to set different styles for different message types.
Created attachment 206531 [details] [review] wizard: Properly handle failure on OS detection Display an error in notification and go back to previous step.
These patches address the 'better job of handling errors during the analysis step' part but not the actual issue. While I agree that we really should check caps of host/qemu/libvirt before creating a VM assuming those caps, we'll need to hack libvirt to fix this particular "issue". I wrote "issue" because I think this is more an integration issue and qemu really should be built with spice support in Fedora (and other distro) packages.
Created attachment 206593 [details] [review] wizard: Properly handle errors during 'prepare' step Display an error in notification and go back to previous step. Perhaps we should notify user of errors from 'create' as well but that needs some thinking as in that step we get errors from libvirt/osinfo with messages that will be totally cryptic to users.
Review of attachment 206593 [details] [review]: since those strings are shown to the user they should be translatable
Created attachment 206599 [details] [review] wizard: Properly handle errors on 'prepare' & 'create' Display an error in notification and in case of 'prepare', we go back to previous step since user is very likely to be able to fix the issue. The error message displayed at failure from 'create' is not very useful but we don't want to show cryptic error messages to user and we really should aim to make it (almost) impossible to get errors from 'create'.
Created attachment 206600 [details] [review] More generic notification bar Now its also possible to display errors through notification bar and new types of messages are now trivial to add. It is also now visible in all UI states except for 'DISPLAY'. Do we want it there? Not sure if this is an issue for us but the colors of Gtk.InfoBar remain always the same regardless of type of message. While we do set the appropriate message type on the Gtk.InfoBar, we set our own style on it as well. So if we need this, we need to figure how to set different styles for different message types.
The updated patch missed to mark a single string as translatable: - throw new Boxes.Error.INVALID ("the URI is invalid"); + throw new Boxes.Error.INVALID ("Invalid URI");
Created attachment 206931 [details] [review] wizard: Properly handle errors on 'prepare' & 'create' Display an error in notification and in case of 'prepare', we go back to previous step since user is very likely to be able to fix the issue. The error message displayed at failure from 'create' is not very useful but we don't want to show cryptic error messages to user and we really should aim to make it (almost) impossible to get errors from 'create'.
Created attachment 207035 [details] [review] wizard: Properly handle errors on 'prepare' & 'create' Display an error in notification and in case of 'prepare', we go back to previous step since user is very likely to be able to fix the issue. The error message displayed at failure from 'create' is not very useful but we don't want to show cryptic error messages to user and we really should aim to make it (almost) impossible to get errors from 'create'.
Created attachment 207036 [details] [review] More generic notification bar Now its also possible to display errors through notification bar and new types of messages are now trivial to add. It is also now visible in all UI states except for 'DISPLAY'. Do we want it there? Not sure if this is an issue for us but the colors of Gtk.InfoBar remain always the same regardless of type of message. While we do set the appropriate message type on the Gtk.InfoBar, we set our own style on it as well. So if we need this, we need to figure how to set different styles for different message types.
So ACK or NACK? I think we better get this in before the freeze?
Review of attachment 207036 [details] [review]: ack
ping
(In reply to comment #16) > ping to who? You only ack'ed one of the patches :)
Review of attachment 207035 [details] [review]: ack (the patch didn't show up in the patch summary somehow..)
Created attachment 207655 [details] [review] More generic notification bar Now its also possible to display errors through notification bar and new types of messages are now trivial to add. It is also now visible in all UI states except for 'DISPLAY'. Do we want it there? Not sure if this is an issue for us but the colors of Gtk.InfoBar remain always the same regardless of type of message. While we do set the appropriate message type on the Gtk.InfoBar, we set our own style on it as well. So if we need this, we need to figure how to set different styles for different message types.
Created attachment 207656 [details] [review] wizard: Properly handle errors on 'prepare' & 'create' Display an error in notification and in case of 'prepare', we go back to previous step since user is very likely to be able to fix the issue. The error message displayed at failure from 'create' is not very useful but we don't want to show cryptic error messages to user and we really should aim to make it (almost) impossible to get errors from 'create'.
Attachment 207655 [details] pushed as c9505f2 - More generic notification bar Attachment 207656 [details] pushed as 2502424 - wizard: Properly handle errors on 'prepare' & 'create'