[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
Re: [Qemu-devel] GTK UI is now the default, Anthony Liguori, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Paolo Bonzini, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Jan Kiszka, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Anthony Liguori, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Paolo Bonzini, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, mdroth, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Anthony Liguori, 2013/02/22
- Re: [Qemu-devel] GTK UI is now the default, Jan Kiszka, 2013/02/22