qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: Re: [UI] suggestion


From: Lionel Ulmer
Subject: Re: [Qemu-devel] Re: Re: [UI] suggestion
Date: Wed, 1 Sep 2004 20:09:30 +0200
User-agent: Mutt/1.2.5i

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]