qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] GTK UI is now the default
Date: Fri, 22 Feb 2013 10:55:48 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Jan Kiszka <address@hidden> writes:

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

There is both a GTK_STOCK_SELECT_FONT stock item and a
GtkFontSelectionDialog so this is actually really easy.  Persistance is
really the only issue here.

Regards,

Anthony Liguori

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]