Hide Forgot
Description of problem: With virt-manager-3.0.0-1.fc33.noarch, I can no longer use keyboard shortcuts properly, because they affect the VM window rather than be sent to the VM itself. For example, pressing Ctrl+W in a terminal inside the VM should delete the last word, but instead it closes the VM window. In the past few days, I've closed my VM windows unintentionally dozens of times. This of course affects other keyboard shortcuts as well, this is just one example. It seems I need to place the mouse cursor inside the VM window to make these shortcuts go inside the VM. That's very inconvenient, because it requires constant thinking of where the cursor currently is, moving it around all the time (which means moving my hand from the keyboard to grab it), and when working with multiple VMs, this is doubly inconvenient. With virt-manager-2.2.1-3.fc32.noarch everything works as expected, the keyboard shortcuts are sent into the VM when the VM window is focused, and the mouse cursor placement is not important. Also, with this version, there is a configuration checkbox in the options to configure this. With the newer virt-manager version, the checkbox seems gone. I'm not sure if this is a bug or a feature. But please do not require exact cursor position to send the keyboard shortcuts into the VM. This very much feels like forcing the "focus follows the mouse" window manager functionality, which I never liked. Version-Release number of selected component (if applicable): virt-manager-3.0.0-1.fc33.noarch Fedora 33 X11 How reproducible: always Steps to Reproduce: 1. open terminal with bash in a VM, type something 2. make sure the mouse cursor is not inside the VM window 3. hit Ctrl+W to to delete the last word 4. see the VM window close 5. try to same thing with virt-manager-2.2, the word is properly deleted
Thanks for the report, that's nasty for sure. FWIW This is due to the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1824480 I was attempting to follow the virt-viewer behavior here. The problem with the old behavior is that while the console was open there was no way to get access to window mnemonics (Alt+F for file etc), not even by clicking outside the console or on the window title. The simplest thing is to make the details window shortcuts non-colliding. If nothing in the VM window is registered to handle Ctrl+W then it will get passed through to the VM. FWIW The keyboard behavior following the mouse location is not a deliberate choice of virt-manager, it's basically the default keyboard grab behavior of the spice-gtk widget. I will study this some more and to see if there's other options.
Thanks for looking into this, Cole.
In git master I changed the window accelerators from ctrl+XXX to ctrl+shift+XXX. Similar to what gnome-terminal defaults to. Otherwise the behavior is unchanged. I want to avoid going back to the old behavior because it was inconsistent in a handful of ways (things like alt+tab were sent to the host when pointer was outside the window for example even though VM window accelerators/mnemonics still weren't available) Kamil can you give that a try and see if it works for you? git clone https://github.com/virt-manager/virt-manager cd virt-manager ./virt-manager
FEDORA-2020-c30055ffe4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c30055ffe4
FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c30055ffe4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c30055ffe4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hey Cole, sorry for a late reply. The change with Ctrl+W is definitely an improvement, I no longer close my VMs by accident. The menu bar shortcuts are active all the time unless I move my cursor to the VM, which is a bit unfortunate, but it shouldn't happen too frequently and I'll get used to it.
FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.