From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LLvao-0005T7-RP for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:22:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LLvao-0005SN-72 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:22:46 -0500 Received: from [199.232.76.173] (port=50797 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LLvan-0005S3-Vn for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:22:46 -0500 Received: from mx20.gnu.org ([199.232.41.8]:20293) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LLvan-0002Kk-F2 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:22:45 -0500 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LLvam-0004VR-BH for qemu-devel@nongnu.org; Sun, 11 Jan 2009 03:22:44 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0B8MhNn030586 for ; Sun, 11 Jan 2009 03:22:43 -0500 Message-ID: <4969AC51.8070406@redhat.com> Date: Sun, 11 Jan 2009 10:22:41 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Ongoing changes to the displaying code References: <4966ADD4.5090102@codesourcery.com> <4966BB7A.3090303@codemonkey.ws> <4966BEC4.7080903@codemonkey.ws> In-Reply-To: <4966BEC4.7080903@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > > I assume you're looking to do this in order to support functionality > like in the Android simulator. So that if you're using QEMU to > emulator a hand held device (cell phone, whatever), you can have > something that looks like that device. > > The problem is, your GUI is going to want all the feature of a normal > GUI. Context menus, perhaps a tool bar, etc. Maybe you want animated > button clicks or even the buttons to make noises when clicked. > Inevitably, it'll bloat to a full blown GUI. Not very useful for us > virtualization folks so we'll also want our own GUI. Then things get > ugly because should it be one GUI or two separate ones? Another way > to do this is to separate out the GUI logic so it's not directly tied > to QEMU. This has been discussed many times and there are a lot of > advantages to using an external GUI. Namely, you can close the window > without exiting the simulation. > Instant messaging clients seem to have solved this without resorting to multiple processes. > If you build a simple app that exec()'s and connects to QEMU via VNC, > and use something like gtk-vnc, you could build just what you're > looking for very easily. It's all portable to Windows too and LGPL > licensed. You could even develop in a higher level language like > Python and you'd get to use file dialog widgets, context menus, and > all that good stuff without worrying about recreating that in SDL. > > I think that's a better route to go for this sort of thing. If you > think it's generally useful, I think it'd also be worthwhile to host > within the QEMU project. I just don't think it's the right thing to > add into QEMU directly. Or it could be done as a separate executable that links to a libqemu.so; the standard qemu binary could be implemented the same way. Applications spanning multiple processes are clunky and inefficient. -- error compiling committee.c: too many arguments to function