Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility

[Kevin Wolf <kwolf@redhat.com>]

Am 20.02.2012 13:17, schrieb Kevin Wolf:
> Am 20.02.2012 00:44, schrieb Anthony Liguori:
>> Hi,
>>
>> 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.
> 
> It's not quite obvious what the build dependencies are. In my case I had
> to install vte-devel. Especially if we're going to make it the default,
> I think configure should print a helpful warning. (In fact, SDL has the
> same problem and I have answered too many questions of users that
> wondered why no window appeared, not understanding that they built only
> VNC).
> 
> I think the series is a good start, just some random thoughts and things
> that I noticed:
> 
> * git complains about some trailing whitespace
> 
> * Half of the menu entries appears to be translated by the libraries
>   used. Give me something that is all German or something that is all
>   English. Mixed languages looks unprofessional.
> 
> * Ctrl-Alt-= as shortcut for Zoom In isn't easy to remember and only
>   makes some sense on a US keyboard layout.
> 
> * The monitor display size always has the same size as the VGA tab now.
>   That can be quite small in text mode and you can't resize any more.
> 
> * The window has a button for maximising, but it doesn't really do
>   anything.
> 
> * Ctrl-PgDn/PgUp does change the tab as I expected on VGA, it's ignored
>   by the monitor and the serial0 tabs. parallel0 segfaults on any key
>   press.
> 
> * When the tab bar is enables, the cursor up key in the VGA tab selects
>   the tab bar. It also is sent to the guest the first time, but when
>   the tab bar is selected, the guest doesn't get any input any more.
>   Makes it rather hard to use the shell history in the guest.

There's more fun...

* The F10 key activates the menu instead of being passed to the guest.
  Just like cursor up even when the keyboard is grabbed. Makes sendkey
  close to the primary interface for keyboard. :-(

* On one start something went wrong, apparently with the zoom (at least
  I saw for a moment how half a letter was rendered over the whole
  screen). Hung my machine until the OOM killer came to the rescue...

Kevin