qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2)
Date: Mon, 27 Feb 2012 14:26:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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.

> 
>> - 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.

> 
>> - 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.

> 
>> - 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.

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.

> 
>>
>> Will see if I find some time to look into this.
>>
>> Is this also working properly under Windows? Otherwise we probably can't
>> deprecate SDL - or would have to provide a native Windows GUI.
> 
> It should, but it doesn't right now most likely because of the glib
> event loop being broken on win32.

Sounds great.

> 
>> As we have a menu now, I would suggest to add some handy monitor
>> commands there as well, like reset or powerdown.
> 
> Absolutely.  I wanted to start with something very simple though first.
> 
> Regards,
> 
> Anthony Liguori
> 
>> Jan
>>
> 

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]