From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S223J-0001NM-CJ for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:59:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S223H-0003cZ-LY for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:59:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S223H-0003cV-DP for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:59:47 -0500 Message-ID: <4F4B9B33.9050506@redhat.com> Date: Mon, 27 Feb 2012 16:03:15 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1330299995-8688-1-git-send-email-aliguori@us.ibm.com> <4F4B9223.70803@redhat.com> <4F4B9587.8060706@us.ibm.com> In-Reply-To: <4F4B9587.8060706@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 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: Anthony Liguori Cc: Stefan Weil , Paolo Bonzini , qemu-devel@nongnu.org, Alex Graf Am 27.02.2012 15:39, schrieb Anthony Liguori: > 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. Yeah, would be better than nothing. >>> - 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. At least grabbing the keyboard manually with Ctrl-Alt-G doesn't disable the accelerators, so even then you can't use these keys inside the VM. > 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. Probably. But not for things as common as Alt-F, Alt-V or F10. Having to use sendkey or the menus for these would be ridiculous and make SDL the friendlier user interface again. Can accelerators only be enabled or disabled all at once? Or could we say that we disable everything that doesn't include Ctrl-Alt and provide an alternative accelerator for activating the menu, like Ctrl_Alt-M? Kevin