From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S212B-0008FB-H1 for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:54:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2129-0008UX-7n for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:54:35 -0500 Received: from goliath.siemens.de ([192.35.17.28]:28442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2128-0008UQ-UI for qemu-devel@nongnu.org; Mon, 27 Feb 2012 08:54:33 -0500 Message-ID: <4F4B8B12.2080401@siemens.com> Date: Mon, 27 Feb 2012 14:54:26 +0100 From: Jan Kiszka 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> <4F4B860C.30404@codemonkey.ws> <4F4B8858.7060202@siemens.com> <4F4B8A2E.1030209@codemonkey.ws> In-Reply-To: <4F4B8A2E.1030209@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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: Kevin Wolf , Stefano Stabellini , Stefan Weil , "qemu-devel@nongnu.org" , Alex Graf , Paolo Bonzini On 2012-02-27 14:50, Anthony Liguori wrote: > On 02/27/2012 07:42 AM, Jan Kiszka wrote: >> On 2012-02-27 14:33, Anthony Liguori wrote: >>>> 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. >> >> This would be a usability regression. It is very unhandy to switch >> between grabbed and ungrabbed, specifically for alt-tab, when working >> with guests vs. host windows. Look e.g. at how rdeskop works in this >> regard. That's why I introduced this feature to QEMU, and I would not >> want to see it die again with the introduction of GTK. > > I'll add a "Grab on Hover" menu item to enable the behavior. It's a good excuse > to look at gconf to store GUI preferences too. Perfect. > >>>>>> - 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. >> >> OK for aspect-ratio-correct scaling of the guest view from my POV. And >> if there is a use case for the old behavior, we could still add a switch >> to the menu for selecting the scaling mode. > > Okay, I'll look into 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. >>> >>> Any suggestions? Display? Graphics? >>> >>> Or were you thinking something like Cirrus VGA? >> >> VGA is (mostly) x86. Also, we may once have multiple guest screens, >> maybe even multiple types of them. So picking up some telling front-end >> name would likely scale best. > > Display 0? > > I think Monitor would be more natural but obviously that would conflict with the > human monitor. It might also be something else than a "monitor" that visualizes guest graphic-like output. Another effect I just noticed: The scroll position of the monitor console is not always properly restored when switching from other consoles. Looks like it can move down, leaving the visible range after some switches. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux