Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/27/2012 07:26 AM, Jan Kiszka wrote:
> On 2012-02-27 14:10, Anthony Liguori wrote:
>> On 02/27/2012 02:21 AM, Jan Kiszka wrote:
>>> On 2012-02-27 00:46, Anthony Liguori wrote:
>>>> I realize UIs are the third rail of QEMU development, but over the
>>>> years I've
>>>> gotten a lot of feedback from users about our UI.  I think everyone
>>>> struggles
>>>> with the SDL interface and its lack of discoverability but it's worse
>>>> than I
>>>> think most people realize for users that rely on accessibility tools.
>>>>
>>>> The two pieces of feedback I've gotten the most re: accessibility are
>>>> the lack
>>>> of QEMU's enablement for screen readers and the lack of configurable
>>>> accelerators.
>>>>
>>>> Since we render our own terminal using a fixed sized font, we don't
>>>> respect
>>>> system font settings which means we ignore if the user has configured
>>>> large
>>>> print.
>>>>
>>>> We also don't integrate at all with screen readers which means that
>>>> for blind
>>>> users, the virtual consoles may as well not even exist.
>>>>
>>>> We also don't allow any type of configuration of accelerators.  For
>>>> users with
>>>> limited dexterity (this is actually more common than you would
>>>> think), they may
>>>> use an input device that only inputs one key at a time.  Holding down
>>>> two keys
>>>> at once is not possible for these users.
>>>>
>>>> These are solved problems though and while we could reinvent all of this
>>>> ourselves with SDL, we would be crazy if we did.  Modern toolkits,
>>>> like GTK,
>>>> solve these problems.
>>>>
>>>> By using GTK, we can leverage VteTerminal for screen reader
>>>> integration and font
>>>> configuration.  We can also use GTK's accelerator support to make
>>>> accelerators
>>>> configurable (Gnome provides a global accelerator configuration
>>>> interface).
>>>>
>>>> I'm not attempting to make a pretty desktop virtualization UI.  Maybe
>>>> we'll go
>>>> there eventually but that's not what this series is about.
>>>>
>>>> This is just attempting to use a richer toolkit such that we can
>>>> enable basic
>>>> accessibility support.  As a consequence, the UI is much more usable
>>>> even for a
>>>> user without accessibility requirements so it's a win-win.
>>>>
>>>> Also available at:
>>>>
>>>> https://github.com/aliguori/qemu/tree/gtk.2
>>>>
>>>> ---
>>>> v1 ->   v2
>>>>    - Add internationalization support.  I don't actually speak any
>>>> other languages
>>>>      so I added a placeholder for a German translation.  This can be
>>>> tested with
>>>>      LANGUAGE=de_DE.UTF-8 qemu-system-x86_64
>>>>    - Fixed the terminal size for VteTerminal widgets.  I think the
>>>> behavior makes
>>>>      sense now.
>>>>    - Fixed lots of issues raised in review comments (see individual
>>>> patches)
>>>>
>>>> Known Issues:
>>>>    - I saw the X crash once.  I think it has to do with widget sizes.
>>>> I need to
>>>>      work harder to reproduce.
>>>>    - I've not recreated the reported memory leak yet.
>>>>    - I haven't added backwards compatibility code for older
>>>> VteTerminal widgets
>>>>      yet.
>>>
>>> Looks quite nice but still has some rough edges:
>>> - full screen doesn't work, at least here
>>
>> How does it fail?
>
> The window changes to resizable mode, but remains a decorated window.
>
>> It works for me.  What distro are you on?
>
> OpenSUSE 11.4, gnome2.

Okay, I'll setup a system and test it out.

>>> - lacking support for auto-grabbing in absolute mouse mode
>>
>> What do you mean by auto grabbing?
>
> That all keyboard inputs are grabbed when the mouse is in the window and
> you don't need to press ctrl-alt-g explicitly. And the reverse should
> happen when the mouse reaches the window border. Just like under SDL,
> give it a try.

Right, this was intentional.  I think it's weird that a window would steal input 
when the mouse moves over it breaking desktop accelerators like alt tab.  If 
you've ever alt-tab cycled through windows when QEMU is running, if you're 
unlucky enough to have the mouse where a QEMU window may be, the QEMU instance 
will steal input and prevent alt-tab from working anymore.

>>> - unscaling (ctrl-alt-u) is lacking
>>
>> Since we scale by 25% up and down, I figured it wasn't strictly
>> necessary anymore because it's very easy to zoom back to the original
>> size.  It's easy enough to add though.
>
> It's mandatory for usability IMHO. You find this "back to 1:1 view" in
> almost every application that supports scaling of its view, and we even
> have a pre-defined shortcut for it for some releases now.

I'll add it.

>>> - window not resizable (except in broken full-screen mode)
>>
>> That's intentional.
>
> And a mistake IMHO. Definitely for the text consoles, but one can also
> argue about the guest graphic console. I think Stefano once introduced
> this for some Xen use case, maybe he can comment on it.

If we added resize, I wouldn't want to scale-to-size.  I find this behavior to 
be more trouble than it's worth.  I'd want to render the VGA screen with a black 
border only scaling based on the zoom settings.

> BTW, "VGA" is the wrong term for the graphic console. Maybe there is the
> real front-end name available somewhere and could be used instead.

Any suggestions?  Display?  Graphics?

Or were you thinking something like Cirrus VGA?

Regards,

Anthony Liguori