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

[Anthony Liguori]

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