From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20hR-0000zH-2j for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:33:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S20hP-0004eX-AD for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:33:08 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:60847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S20hP-0004eM-0N for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:33:07 -0500 Received: by pbbro12 with SMTP id ro12so6450057pbb.4 for ; Mon, 27 Feb 2012 05:33:05 -0800 (PST) Message-ID: <4F4B860C.30404@codemonkey.ws> Date: Mon, 27 Feb 2012 07:33:00 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1330299995-8688-1-git-send-email-aliguori@us.ibm.com> <4F4B3CF0.5040703@web.de> <4F4B80D8.6010000@codemonkey.ws> <4F4B8484.7060109@siemens.com> In-Reply-To: <4F4B8484.7060109@siemens.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/8] Add GTK UI to enable basic accessibility (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Kevin Wolf , Stefano Stabellini , Stefan Weil , Alex Graf , qemu-devel@nongnu.org, Paolo Bonzini 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