On Tue, Feb 20, 2007 at 10:39:46AM +0000, Mark McLoughlin wrote: > Hi Dan, > Cool stuff ... > > On Tue, 2007-02-20 at 04:21 +0000, Daniel P. Berrange wrote: > > > As I said this is the first iteration just to get the UI up and running. > > Once people have played around with it, I fully expect some UI tweaks to > > improve the user experiance. > > Some suggestions: > > - It'd be really nice not to have the connect dialog when you start > up virt-manager - e.g. think of a first time user who selects > "Virtual Machine Manager" from the menus and is then asked about > "Open a connection" ... that's fairly intimidating > > - Perhaps by default connect to Xen if run as root, and connect to > QEMU when run as non-root Yes, that pretty much aligns with what i was thinking. Anticipating the remote management, the flat list of VMs would change to a tree list with two levels, the first being the host, the second being the VMs on that host. Saving the list of URIs for managed hosts in GConf so we don't need to ask the user each tim ethe app runs - and neatly avoid having to put up the initial connect dialog at startup. We'd also automatically connect to either Xen or QEMU on the local host according to which was available. > - I'd be tempted[1] to not expose the notion of different hypervisors > in the UI beyond that. Maybe have a --qemu command line option or > something. If we do need to expose this in the UI, I think the most > natural place is in the "create VM" dialog[2]. We can already specify at arbitrary libvirt connect URI on the command line via the arg '--connect URI', so we have a fallback option for experts to use. > - Also, suggest "Connect to" rather than "Open a connection", the > latter concept would probably only make sense to programmers Or 'Connect to host'. > - I think I'd only use the "Connect to" concept with remote > management - connecting to a remote machine is a well understood > concept, but connecting to a hypervisor is a little weird. Perhaps > "Manage Xen guests" vs. Manage QEMU guests" as abovea I like the idea of just picking Xen or QEMU as appropriate (root vs non-root) and allowing people to use the --connect command line arg if desired. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|