From: "Jim C. Brown" <jma5@umd.edu>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: QEMU 0.7.2
Date: Mon, 12 Sep 2005 22:56:14 -0400 [thread overview]
Message-ID: <20050913025614.GB21668@jbrown.mylinuxbox.org> (raw)
In-Reply-To: <43261E56.3030406@us.ibm.com>
On Mon, Sep 12, 2005 at 07:33:26PM -0500, Anthony Liguori wrote:
> What's more, it seems like the easiest way, given the
> way QEMU currently works, to have an advanced GUI that can manage
> multiple instances of QEMU (using tabs or something like that).
>
I'm working on something like that (though I stole the idea from Q, the Mac OS X
Cocoa GUI for qemu). The way it works, one master qemu process creates the
actual window (with full GUI and etc), as well as a VM for one guest. In order
to handle multiple guests, subprocesses are spawned (so one VM per process) but
they display to the GUI of the master process. (Actually, this is implemented
using GtkSocket and GtkPlug.) Currently you'll only be able to see one guest
at a time (though you can switch among them at any time), but I plan on adding
support for using multiple windows later (all windows would be owned and controlled by
the same master process).
> There can then be separate GTK/QT guis without QEMU having to support
> both widget sets.
Or either (except some minimal GDK and the GtkPlug). There are definite
advantages to going this route.
AFAIK Fabrice isn't supported of externel GUIs for qemu. He wants to have the
code as part of qemu. (He has no preference however. GTK or Qt or something else
will be fine, as long as it works, the code is simple, and it is easy to use.)
> Then another application (running as a separate process) can use a
> GtkSocket to embed the QEMU vga device within a larger GUI.
>
It would be nice if we could keep some sort of GUI-less mode (like what we have
now), so that we only have to run one executable/process in order to run a guest.
> Regards,
>
> Anthony Liguori
>
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
next prev parent reply other threads:[~2005-09-13 3:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-04 17:27 [Qemu-devel] QEMU 0.7.2 Fabrice Bellard
2005-09-05 9:58 ` [Qemu-devel] " Christian Walther
2005-09-05 10:48 ` Andreas Mohr
2005-09-05 10:59 ` Christian MICHON
2005-09-08 14:18 ` Jim C. Brown
2005-09-12 22:55 ` Karl Magdsick
2005-09-13 0:33 ` Anthony Liguori
2005-09-13 2:56 ` Jim C. Brown [this message]
2005-09-13 3:37 ` Mike Swanson
2005-09-13 3:47 ` Anthony Liguori
2005-09-13 3:54 ` Jim C. Brown
2005-09-13 3:45 ` Anthony Liguori
2005-09-13 13:07 ` Jim C. Brown
2005-09-13 2:43 ` Jim C. Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050913025614.GB21668@jbrown.mylinuxbox.org \
--to=jma5@umd.edu \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).