[Top][All Lists]
[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/