Re: [Qemu-devel] GTK UI is now the default

[Anthony Liguori]

Jan Kiszka <address@hidden> 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.

>  - 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.

>  - 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.

>  - 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.

Regards,

Anthony Liguori

> If you have any ideas on how to address some of the issue, let me know,
> I can try to look into them. But I would also test patches.
>
> Jan
>
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux