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

[Jan Kiszka]

On 2013-02-22 16:14, Anthony Liguori wrote:
> 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.

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