On 2013-02-22 16:14, Anthony Liguori wrote: > Jan Kiszka <jan.kis...@siemens.com> writes: > >> On 2013-02-22 10:56, Jan Kiszka wrote: >>> On 2013-02-22 00:04, Anthony Liguori wrote: >>>> >>>> Since this is a pretty visible change for a lot of people, I thought I'd >>>> send a top level note. The GTK UI is now committed and is the default >>>> UI provided it's available. >>>> >>>> For anyone counting, it's been a little more than 7 years in the making: >>>> >>>> http://article.gmane.org/gmane.comp.emulators.qemu/9726 >>>> >>>> If you want to try it, make sure you have the gtk-2.0 development >>>> packages installed and the VTE development packages. >>> >>> What's your plan now regarding persistent configuration? I'd like to >>> make "Grab on hover" default here as it is how I'm used to work with >>> SDL, but also other tools like rdesktop. Clicking on some menu item each >>> time I start a guest is obviously no solution. >>> >>> Then, any concerns about adding a "control" menu? Something to issue >>> standard tasks without monitor interaction ("power down", "reset", "stop")? >> >> Some smaller quirks I stumbled over so far: >> - text consoles use an inferior font compared to SDL (ideally, that >> one should also be used for GTK) > > It uses whatever your system font is.
We need to make this configurable. Just stumbled over Kraxel's qemu-gtk which did the same. I use "Misc Console" in all my terminals, and so should my QEMU look like one day. Another reason to have persistent configuration. > >> - text consoles in unscaled mode do not use their fixed default size >> but the one the guest display is using > > This is extremely hard to avoid. The VteTerminal is a child of a > GtkNotebook. The GtkNotebook can only have one size. The only widget > setting a size request right now is the VGA widget and so everything > else adapts to that. > > I've tried to change this but so far haven't been successful. GTK is > pretty quirky about calculating window size. Indeed. I'm always seeing a 80 x (configured_height - 1) console here. OK, food for a long weekend. > >> - switching between graphical and and text consoles quickly messes the >> scaling of the guest display up > > I can reproduce this. Specifically, you have to change modes while the > guest resizes the display. > > What happens is you start out at 640x480, then switch to the VteTerminal > and while on the terminal, the guest resizes to 720x400. > > Since the VGA tab isn't being displayed, the window size isn't being > changed however when you switch back, you now have a scaled display > because we calculate the scaling factor based on the observed window > size. > > I think we just need to more clearly define when zoom isn't enabled and > not change the scaling factor. Noted. > >> - pressing ALT+menukey sends the ALT-down event to the guest, but not >> some ALT-up, leaving the guest keyboard in a confusing state > > We handle accelerators in gd_window_key_event(). > > if (!handled && propagate_accel) { > handled = gtk_window_activate_key(GTK_WINDOW(widget), key); > } > > <- note here -> > > if (!handled) { > handled = gtk_window_propagate_key_event(GTK_WINDOW(widget), key); > } > > At that point, we know whether an accelerator was activated but we don't > know whether the key events were going to the guest. > > We probably need to keep a modifier map and have the ability (much like > in VNC) to reset modifier state on certain events. Accelerator > activation is probably a good point to reset modifier state to the guest > (along with leave-notify). > > gtk-vnc has code to handle this, we should probably look at using that > as a starting point. OK. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux