On Fri, Jan 9, 2009 at 4:04 AM, Anthony Liguori
<address@hidden> 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.
+1 to separate the emulation logic and the display/GUI one. this is exactly what has been done in the Android emulator, even though the program uses its own GUI for practical reasons.
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.
For my specific needs, VNC and a separate GUI application are
totally overkill. However, it is true that QEMU itself absolutely doesn't require to support any GUI jazz (you should probably let that to forks/GUI wrappers instead).
On the other hand, it would be nice to have a slightly better way to decouple display/events between the emulation and user-interaction parts of the system. For example, I've attached the framebuffer abstraction that I currently use in the Android emulator source code (it's a well documented header file).
It's basically a slightly better DisplayState, with explicit producer/clients relationships and a global fifo used for initialization/linking. I do not claim it is the absolute best way to do it, just an example on how this can be implemented.
If someone's interested, I can probably provide a patch against the QEMU svn sources.
Regards,
- Digit
Regards,
Anthony Liguori
Regards,
Anthony Liguori
framebuffer.h