On Fri, Jun 21, 2019 at 07:14:56PM -0400, Cole Robinson wrote: > On 6/19/19 6:34 PM, Cole Robinson wrote: > > Hi all, > > > > I've drafted a wiki page about virt-manager UI philosophy, for lack of a > > better term, suggestions welcome. The intention here is to provide some > > guidance about what types of things we want to expose in the UI, both to > > devs, potential contributors, and users requesting RFEs. > > > > https://github.com/virt-manager/virt-manager/wiki/WIP-UI-philosophy > > Following on from the UI philosophy document, here's a list of features > in current virt-manager/virt-install features that I think are > candidates for removal. > * the migration wizard: migration is IMO an advanced use case. It > requires host config outside of virt-manager to have a chance of > working. the only place migration is really critical for users is > serious multihost production scenarios where virt-manager isn't really > appropriate per the UI philosophy. And besides some UI friendliness > virt-manager doesn't really add much over virsh IMO. Nearly every bug I > can recall about its usage was from one person who happens to be a > co-worker developing qemu migration, and redhat QE, which means it's > either perfect or no one uses it :) I think it should go I'm not really convinced by this, as I think it dumbs down virt-manager too much. Telling GUI users to use virsh instead is not a very compelling story IMHO. virt-manager has multi-host as a feature, and so I think it is reasonable to expect it to support migration. It isn't only large openstack scale deployments that can find it useful. > * console scaling options (always, never, fullscreen): we've had this in > the UI forever, but I don't think it has much usage. virt-viewer doesn't > even expose it how we do, instead it just has a zoom option which I > don't think we need to implement either. just today there was a bug > reported saying that scale->always is fairly obviously broken and has > been for a few releases, which makes me think no one is using it. > dropping this could be part of a larger think of how console sizing > works, if we should default to spice auto-resize, or if there's some > more modern config we should be taking care of. > https://bugzilla.redhat.com/show_bug.cgi?id=1722088 The right answer is different for VNC vs SPICE. For VNC you just want to resize the main window to fit, if possible, otherwise scale it down. No compelling reason to want to be scaling up. For SPICE though if the guest agent is present then you want to guest display to auto-resize to match whatever the host window allows to display. That way you never need scaling down. > * graphics keymap stuff. in virtinst/hostkeymap.py we have some logic > to parse host keymap from various locations like /etc/vconsole.conf and > try to map it to a qemu keymap name. You can trigger this via the UI in > the keymap dropdown 'Copy local keymap' and via virt-install --graphics > keymap=local, though the latter isn't even documented. This all was > the default behavior we used and essentially needed years ago, but > qemu and spice-gtk/gtk-vnc have for a decade been able to route > around the need by sending raw scancodes back and forth. This code > could in theory still be valuable for someone to set the keymap to > work with a vncviewer for example which doesn't have the scancode > support IIRC, but I think at that point we can just ask them to specify > the keymap themselves. So I propose killing hostkeymap entirely, making > keymap=local print a cli warning, and drop the keymap dropdown from the > UI. Users can set it in the XML editor if they need it Yes, there's no compelling reason to set the keymap - even non-gtk-vnc based clients like tigervnc support the scancode mode now. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
