qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Ongoing changes to the displaying code


From: Avi Kivity
Subject: Re: [Qemu-devel] Ongoing changes to the displaying code
Date: Sun, 11 Jan 2009 10:22:41 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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.


Instant messaging clients seem to have solved this without resorting to multiple processes.

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.

Or it could be done as a separate executable that links to a libqemu.so; the standard qemu binary could be implemented the same way.

Applications spanning multiple processes are clunky and inefficient.

--
error compiling committee.c: too many arguments to function





reply via email to

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