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

[Anthony Liguori <aliguori@us.ibm.com>]

On 02/27/2012 08:24 AM, Kevin Wolf wrote:
> Am 27.02.2012 00:46, schrieb Anthony Liguori:
>> 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
>
> Looks like I need to 'make install' before I can use the translations? I
> don't have any qemu version installed into the system, but always run it
> from to build directory (I would only confuse the different trees if
> something was installed). Shouldn't it be possible that qemu finds the
> right files just like it does with the BIOS etc.?

It's a little harder because of the way gettext works.  You can only have a 
single search path AFAICT.

We could add a --with-localedir= to configure and then rearrange the po/ 
structure.  Then you would do something like:

./configure --with-localedir=$(pwd)/po

And it would use translations from your build directory.

>>   - 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.
>
> - F10 still activates the menu (same for Alt-F/V)

This is expected behavior although Grab on Hover will cause it to behave like 
SDL does.

F10/Alt-F/V are menu accelerators and we need to allow menu accelerators for 
things like Ctrl-Alt-2 to work.

More importantly, it should be possible to navigate the GUI without a mouse 
(this is an accessibility requirement).  Without supporting Alt-F, there's no 
way to navigate the menu from the keyboard.

That said, we probably do want to add a Send Key menu for sending key sequences 
that are used as accelerators.

Regards,

Anthony Liguo

>
> Kevin
>