On Fri, Jan 9, 2009 at 4:20 PM, Anthony Liguori
<address@hidden> wrote:
I would think the ability to maintain your own GUI and therefore not have to fork QEMU would outweigh the "overkill" factor.
What specifically, do you consider to be overkill? Are you afraid of the performance overhead of VNC? Is the lack of VNC clients a problem (assuming you don't want a gtk dependency)?
Given that there is only one person that works on the Android emulator (me), and that this is unlikely to change in the near future,
I want to avoid any additional complexity with low return on investment (development / support costs).
Simply put it:
I want something simple that "just works" on three different platforms.
I absolutely cannot use a standard VNC client.
I want to distribute the program as a single statically linked executable.
I don't want a GTK/Qt/Whatever dependency.
I can test my UI on one platform and know that it will look and behave exactly the same on other ones
(e.g. no funky behaviour due to slightly different fonts, different versions of the UI toolkit libs, whatever).
I could change my mind on various of these items, but this would invariably require more (or even a lot more) development and support efforts
Finally, the program is *already* accessed and controlled by an external Java development tool (DDMS) which has sophisticated UI elements
Fortunately for me, it's a very specific application that doesn't require a full-blown GUI, and never will :-)
I'm not advocating this path for other projects, just explaining what I do.
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.
I'd like to avoid introducing another remove communication mechanism in QEMU. VNC is extremely flexible so we should be able to do whatever we need to do with it.
Oh, this is not a remote communication scheme at all. This is only a header used to completely decouple the emulation part of the program from the one sending it to the display. it's only better than the current scheme because the UI part doesn't need to include emulation-specific headers just to get the definition of DisplayState, and the role of each party is more clearly documented.
Regards,