We have a SoC working on this. I am not sure that bug is the best way to track the feature progress.

(In reply to comment #1)
> We have a SoC working on this. I am not sure that bug is the best way to track
> the feature progress.

1. We still don't have the UI design for it.
2. The SoC student in question can use this bug to submit her patches.

*** Bug 677692 has been marked as a duplicate of this bug. ***

I've set up a design stub for this at https://live.gnome.org/Design/Apps/Boxes/ImportExport

Here is what I think we can do now:
https://www.dropbox.com/s/z6me8rcds55yzxr/design.png
and then add import/export to the menu. (sorry for the bad lighting)
Basically it's the same design, but as we develop the features we can add more options to this button.

The 'import' part seems different in jimmac's mockups (you double click on a file with the right mime type in Nautilus, or click on a link with the same mime type in Web and it automatically gets imported), but a simple load/save menu works for me, once this is working the UI can be refined as you suggest.

(In reply to comment #5)
> Here is what I think we can do now:
> https://www.dropbox.com/s/z6me8rcds55yzxr/design.png
> and then add import/export to the menu. (sorry for the bad lighting)
> Basically it's the same design, but as we develop the features we can add more
> options to this button.

One big difference is that you are thinking of using 'dialog' for notification. You want to use the internal notificationbar instead. Also I don't think we need step 4: message dialog. The reason for failure will most probably be some lower-level details that user must not be exposed to. Instead we should try our best to ensure things just work (TM) and simply inform the user about success or failure using the notificationbar. Other than that, looks good as starting-point.

Oh but we still want to spit the details of the error to the console as a critical/warning so when things go wrong, we can ask bug reporters for console log and be able to figure whats going on..

Does this also cover importing virtual machines from Virtual Machine Manager?

(In reply to comment #9)
> Does this also cover importing virtual machines from Virtual Machine Manager?

That just uses a different location/connection of libvirt so that needs a different kind of handling: https://bugzilla.gnome.org/show_bug.cgi?id=677691

Did you mean to link to a different bug?

(In reply to comment #11)
> Did you mean to link to a different bug?

Yeah. :) bug#666185

Should have updated this bug with some conclusions we (Me and Jovanka) came-up with last year after discussion with libvirt folks:

http://www.redhat.com/archives/libvir-list/2012-July/msg00127.html

* Ditch the idea of saving/restoring state (at least for the first implementation).
* Create a file format where we can store both storage and (host-agnostic) parts of the domain configuration. One idea would be to have a tar file with custom extension (e.g .boxes).
* The 'import' process would then involve Boxes creating a new VM (like we currently do in wizard) but base the configuration on the host-agnostic configuration in .boxes file.
* We can copy the contents to a new disk *after* creating the VM and show an 'Importing..' message under the VM during the copying (later we can add a progressbar like the one shown in mockups for installing[1]).
* We also probably want to ditch the special 'import' button as we can simply reuse wizard here. That way, user can even modify the props of the VM before creation/launch.

[1] https://github.com/gnome-design-team/gnome-mockups/raw/master/boxes/boxes-install6.png

Thanks for the update Zeeshan. It is really useful. I'm researching on the new model.

We've discussed this some more at the Montreal summit.

Conclusions:
- should support ovf file format
- import is mostly ok
- export: put a button on the selection toolbar, probably pop up a file chooser to select location
   maybe interesting:
   - write directly to a usb stick (?)
   - upload directly to cloud

Seems like comment 15 provides a design for the near future. Removing the ui-review keyword.

ATM 'git grep import help/C' returns only this stub page:
https://git.gnome.org/browse/gnome-boxes/tree/help/C/import-images.page.stub

Until this feature is missing, it would be nice to have some instructions on how to "manually import" an existing box into a new, clean installation.

I've just been helped on IRC and I found out that copying ~/.local/share/gnome-boxes/images is not enough. You must copy also ~/.config/libvirt/qemu/*.xml file(s).

(In reply to Federico Bruni from comment #17)
> You must copy also ~/.config/libvirt/qemu/*.xml file(s).

No you must not, you should use virsh dumpxml/virsh define. I pointed you at ~/.config/libvirt/qemu/*.xml as you only had a backup for your home, but you should have used virsh define on the new machine.

(In reply to Federico Bruni from comment #17)
> ATM 'git grep import help/C' returns only this stub page:
> https://git.gnome.org/browse/gnome-boxes/tree/help/C/import-images.page.stub
> 
> Until this feature is missing, it would be nice to have some instructions on
> how to "manually import" an existing box into a new, clean installation.

That would involve exposing users to commandlines etc. Those instructions are for import of images shared by other people, as just disk images. Supporting that is as far as I'm willing to go, until we have this feature implemented.

*** Bug 760890 has been marked as a duplicate of this bug. ***

-- 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/7.