Hello everyone, as the guy who implemented all this in the Android emulator, I'd like to share a few thoughts. On Fri, Jan 9, 2009 at 4:04 AM, 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. > +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 >> > > > >