qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and sto


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Date: Mon, 26 Oct 2009 11:17:43 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

Avi Kivity wrote:
On 10/26/2009 05:49 PM, Anthony Liguori wrote:
A user starts a VM at a physical box. Everythings fine but he wants to return to his workstation so he closes the window. He goes back to his workstation and connects to a VNC server (on a different X server). He wants to now bring up the guest's display.

Users don't have boxes. They have computers. They don't want to open VNC clients and type in meaningless numerical addresses. They do want GUIs which fit with the OSes theme, cut'n'paste, printing, and shared storage, all easily configurable.

You misunderstood. The VNC session is to the users remote desktop. But drop VNC for a minute, this is the same thing as just closing the window because the VM runs all day and you don't need to see it's display. Like I said, I've never been convinced that this is critical but it's always been a very vocal argument against more GUI functionality.

This cannot be achieved with a gui in the same process as qemu. Is it necessary to support? I don't know.

In the priority list this is about 3000 places below having nice buttons to eject and insert a CDROM. A user with a "box" would probably want to run the guest on a server (and use vnc, etc.).

I do agree with you.

I'd love to just replace the SDL display with GTK + Cairo. I'm even somewhat inclined to suggest linking to python so that the gui can be written in python...

Best would be to just export a QObject binding to scripting languages, which could then be used to implement GUIs outside the qemu source base. The only tricky part is how to deal with the display. Can we expose the display as a special QDict?

I'd expose the display as a GTKWidget derivative. We would load a python program and it could instantiate the widget because we've already loaded it. I wouldn't bother with QObject at all. Just setup an easy way to use QMP from within Python using the natural python types.

The trick only real trick is that the python script has to be launched from a separate thread because Python isn't asynchronous and has a big lock at the binding level. But it works well if you have a socketpair with QMP that is used from the Python thread.

Regards,

Anthony Liguori




reply via email to

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