On 6/24/19 5:09 AM, Daniel P. Berrangé wrote: > 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. > Okay. Given you and Peter's rejection I'm fine with keeping it, it's fairly low maintenance anyways. > >> * 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. > Okay. If I ever make time to give a bigger rethink how we handle console resizing by default, I will make a thread >> * 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. That's good to hear Thanks, Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
