UI request: add a function key toolbar (f1-f12)

[Jim Hall]

I run old DOS programs under FreeDOS using QEMU.

It's common when running/testing DOS applications to use the function keys. Some of these (such as F10) are intercepted by the window system. For example, some DOS program installers use F10 to install the software, but F10 is intecepted by the window system.

The standard solution is to jump to the QEMU console and use sendkey to send a specific function key to the QEMU guest (often needed for 'sendkey f10'). But this does not seem to be very user friendly for new users. Nor is it very fast if you need to this often.

I propose QEMU add a toolbar with the function keys.

I've attached a mockup of one possible design, with a simple toolbar for F1-F12. A possible modification would be to add "modifier" buttons for Ctrl and Shift and Alt to make it easier for users to enter combinations like Ctrl-F12 or Alt-F10 or Shift-F1.

[Daniel Berrange (berrange)]

Adding a toolbar with function keys consumes alot of screen real estate for something that is going to be rarely used in practice.

The more usual approach to this problem is for the application to grab the keyboard and block all local window system accelerators, so that Fn goes straight to the guest OS when the console window has focus. This is done by GNOME Boxes, virt-viewer, virt-manager, and I though QEMU's frontends did it by default too.

Recently though, there has been a regression in this area. With the switch to Wayland instead of Xorg, the standard GTK APIs for doing this keyboard grabbing / accel blocking no longer work correctly. Instead apps need to add custom code to talk to the Wayland compositor IIRC. There's work underway to address this but its a way off.

Some key combinations are hard to deal with, even with the above approach. For that reason virt-viewer/virt-manager, etc typically have a "Send key" menu item, populated with a set of special sequences. Typically this covers Ctrl+Alt+fn sequences, and Ctrl+Alt+Delete and a couple more.

[Peter Wu (lekensteyn)]

Current QEMU code (at least, v2.12.0-329-ge5cd695266) does not grab the F10 key ("menubar activate"), accelerators (Ctrl-Alt-1) or menu bar "mnemonic"s (such as Alt-V for _V_iew).

This comment nicely summarizes what kind of grabs is needed:
https://bugzilla.redhat.com/show_bug.cgi?id=499362#c1
This is the corresponding implementation:
https://github.com/SPICE/virt-viewer/blob/4048d28de853854a57835e91fb8758e78bc9ecd5/src/virt-viewer-window.c#L696

Changing the "gtk-enable-accels" setting on the window should still work in order to disable accelerators such as Ctrl-Alt-G and Ctrl-Alt-1. Being able to switch to the monitor (e.g. to issue "sendkey ..." is important, so something else should probably catch this. Or else just accept that the grab key has to be pressed first.

Alt-M (Menu) and Alt-V (View) are not that commonly used shortcuts, these could be removed/disabled with a grab if desired, but otherwise I am not annoyed by it.

The F10 key however is used for various purposes in applications and must be passed to the guest.
Unfortunately, Timm Bäder removed the "gtk-menu-bar-accel" property in GTK+ 3.22.1-295-gb082fb598d (Oct 2016) which means that the F10 shortcut can no longer be disabled using said property. So now another hack is needed to prevent "gtk_window_activate_key" (gtk/gtkwindow.c) from triggering this menu bar.

[Thomas Huth (th-huth)]

Patch has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=677b490501823c1cb6946d8