On 10/26/2009 05:49 PM, Anthony Liguori wrote:
Many applications minimize to the system tray without needing two
processes.
Minimizing or hiding the window are different use cases. Now, I'm not
100% convinced this use-case is absolutely required but historically,
it's always come up in discussions of improving the qemu gui.
Imagine the following:
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.
(and before someone tells me I don't know what users want - users don't
read qemu-devel, either).
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'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?
--
error compiling committee.c: too many arguments to function
