qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Doing a Tcl/Tk based frontend


From: Anthony Liguori
Subject: Re: [Qemu-devel] Doing a Tcl/Tk based frontend
Date: Thu, 15 Jun 2006 18:38:11 -0500
User-agent: Thunderbird 1.5.0.4 (X11/20060612)

Daniel P. Berrange wrote:
On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote:
On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote:

If you are familiar with Tcl/Tk, maybe you could give some hints on how
to embed the Qemu window into such an app?
Embedding the emulator's window might not be the best way to attack the
problem.  Especially since you would need to be able to detach it to be
able to go full screen.  I have pondered the Tk frontend idea before so
lemme dump my random thoughts on the subject and see how many holes get
punched in em.

With the new VNC server capability there is no need to embed the emulator's
existing window. You can just have a GTK/QT widget which acts as a VNC client
taking the video feed & displaying directly within the GUI management app.

I definitely think this is the write approach too. I'm still at the proof-of-concept phase those. The VNC client code seems to work well (it's asynchronous and uses glib) but I haven't integrated it into a widget just yet.

This is coming straight off my hard drive so YMMV.

http://hg.codemonkey.ws/gvnc/

Similarly you can redirect the QEMU monitor console to a UNIX pipe when lauching QEMU, so the management app can fully control the QEMU engine
to do suspend/resume, snapshots, media changesi.

I wrote an GUI app in Python which did the latter already:

http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html

At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't
hook up the display, but with the 0.8.1 release it wouldn't be much effort
to embed the display directly in the app via VNC. So I don't think there

The tricky part is the VNC widget. Reusing any of the existing vnc clients isn't really an option. The client end of the protocol has way too many states making a state machine really nasty.

I ended up settling on a coroutine based approach which I'm sure will raise some eyes. Of course, one could easily replace the coroutines with threads though (I just have an aversion to threading.

I've also got code laying around for basic software scaling which I also think is important for proper fullscreen support. Just need a little more free time :-)

Regards,

Anthony Liguori

are any changes required in QEMU itself to be able to create a fully
featured QEMU frontend easily on a par with VMWare Desktop, if not better.

Regards.
Dan.





reply via email to

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