Spec URL: http://f1ash.fedorapeople.org/virt-sandbox-runner/testing/virt-sandbox-runner.spec SRPM URL: http://f1ash.fedorapeople.org/virt-sandbox-runner/testing/virt-sandbox-runner-1.0.0-1.fc20.R.src.rpm Description: Qt wrapper for virt-sandbox utility. This application runs and controls the configured jobs, running in a virt-sandbox. Job settings are saved in the application's configuration. This application has Virtual Network Control. Fedora Account System Username: f1ash Additional info: Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6527083
Does this need to be a new top level package? It shares a lot of data with your se-sandbox-runner and looks/functions exactly the same, why not just combine them? Also, I question whether it's a good idea to build a graphical tool around a command line (virt-sandbox), which in itself is a very thin wrapper around an API that you could just use directly instead.
(In reply to Cole Robinson from comment #1) > Does this need to be a new top level package? It shares a lot of data with > your se-sandbox-runner and looks/functions exactly the same, why not just > combine them? > You must understand that these are different types of sandbox. See for: "Background motivation & prototype" (https://www.berrange.com/tags/libvirt-sandbox/). And although their appearance is similar (but not all), but they are made around the different packages are not related to each other. This forces have different applications (which have a similar set of icons). > Also, I question whether it's a good idea to build a graphical tool around a > command line (virt-sandbox), which in itself is a very thin wrapper around > an API that you could just use directly instead. Basically, a graphic interface is designed for ease of setup and storage arguments permanent tasks. This implementation of the sandbox (without API) allows you to run applications in the graphic display terminal and work with them interactively.
Resetting reviewer, no response for several months