From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2Zd2-0002HI-Ns for qemu-devel@nongnu.org; Wed, 01 Sep 2004 14:14:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2Zd1-0002H5-9o for qemu-devel@nongnu.org; Wed, 01 Sep 2004 14:14:40 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2Zd1-0002H2-6X for qemu-devel@nongnu.org; Wed, 01 Sep 2004 14:14:39 -0400 Received: from [62.4.22.179] (helo=mail.bbrox.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C2ZY3-0004nB-P8 for qemu-devel@nongnu.org; Wed, 01 Sep 2004 14:09:32 -0400 Date: Wed, 1 Sep 2004 20:09:30 +0200 From: Lionel Ulmer Subject: Re: [Qemu-devel] Re: Re: [UI] suggestion Message-ID: <20040901200930.A9993@bbland> References: <2781f0204090108435fbed61d@mail.gmail.com> <1094058382.3290.63.camel@aragorn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from look@reply.to on Wed, Sep 01, 2004 at 07:35:44PM +0200 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: daimon55@free.fr, qemu-devel@nongnu.org On Wed, Sep 01, 2004 at 07:35:44PM +0200, Ronald wrote: > Instead of having gui for every platform supported by qemu, the qemu > display could be the ui. This is basically what ScummVM is doing as they have their own 'in-game' GUI system for loading / saving games, choosing the game to 'emulate', ... It's working, but I still thing this is a bit flawed as you will re-invent the wheel (yet another widget library) and it won't be the 'theme' of the native UI. I agree though that this would be pretty nice once QEMU is started for 'in-game UI' as John explained (for example, having the GUI to eject / insert a new CD-ROM to be an overlay instead of having to swap to the console - this would work nicely on people using QEMU full-screen). One could even imagine this overlay alpha blended for all these eye-candy buffs out there. For the whole 'launcher / configuration / choose an image' stuff, I still think a 'native' GUI would be best. And the easiest way to integrate this in QEMU would be to have some driver API. To access the 'screen', a simple 'Lock / Unlock' API would be enough (so a GTK front-end would need to have a GdkImage and just implement these function to write on this image, whereas a Win32 front-end would use, for example, a windowed DirectDrawSurface to do the same). On the other hand, as I only use QEMU on Linux and the command line is just fine for my needs, I won't volunteer for the task of designing the API (just maybe for reviewing it if anyone proposes something). Lionel -- Lionel Ulmer - http://www.bbrox.org/