Jan Kiszka <jan.kis...@siemens.com> writes:
> On 2013-02-22 16:14, Anthony Liguori wrote:
>> Jan Kiszka <jan.kis...@siemens.com> writes:
>>
>>> 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.
BTW, you can configure a system wide "Fixed-width font" in GTK and that
will be used for any VTE widget.
Still should make font configurable in QEMU, but thought I'd mention it.
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
