[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window

From: Christian MICHON
Subject: Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Date: Sat, 28 May 2005 15:17:52 +0200

ok, maybe this needs clarifications. I do not have a Mac, therefore anything
related to cocoa is unknow to me. sorry :(

Let's take an instance of i386-softmmu qemu, which has switched internally
into a 1024x768 graphical mode. To have any gui toolkit AROUND it, the
whole apps, inclusive of the window manager decoration, would need more
than 1024x768 pixels.

When going full screen, as if the qemu machine was the host, we should see
1024x768 pixels only on the screen. The gui toolkit would not be
drawn, therefore
useless unless you switch back to non-fullscreen.

Having the gui toolkit around the instance is ok, provided your native screen
resolution is big enough. But if it's not, you'll need scrollbars, or reduce the
internal graphical mode.

Let's take another concrete example. I have on my desktop a PC with XP
and a LCD 15 inches which support at most 1024x768. When I launch a qemu
instance and the internal softmmu graphical mode is 800x600, how much space
is left on screen, considering the taskbar at the botton and the qemu titlebar ?

100 pixels in height and 200 pixels in x. Not much to integrate a gtk2 toolbars
and a menu, right ? Actually, it will be just nice. only for 800x600
qemu graphic

My point is: what it the controls could be drawn inside the qemu
graphic windows,
like an On-Screen-Display. You would call a menu, overlapping the
current session,
and you could select the controls you want to change (mostly fda and cdrom, or
load/save vm). The advantage of this being inside the main graphic
window is that
even inside a full-screen mode, we could access it.

But I understand Fabrice's point. After all, this is his "baby". :)

On 5/27/05, Pierre d'Herbemont <address@hidden> wrote:
> On 26 mai 05, at 23:07, Christian MICHON wrote:
> > I do not know what cocoa.m implementation is, but I've seen
> > screenshots.
> cocoa.m is just a qemu video driver which uses natives Mac OS X UI
> Libraries.
> > It does require space, and if you go full-screen,
> > you can't do modifications.
> I am not sure that you speak about the cocoa driver. The cocoa video
> driver is lighter than the SDL one, since it doesn't require the SDL
> dependencies. And I don't get the full-screen point: cocoa.m still
> need much work, and that is why it doesn't support fullscreen (yet).
> (BTW Mike has been doing some great improvements which will be
> hopefully soon committed in the head cvs repository.)
> > Hence the suggestion to go
> > full SDL.
> Fabrice would like to see the native GTK, or Win32 qemu video coded.
> Because then a decent UI could be added to qemu. The front ends will
> always be limited, and the previous hack seems a bit crazy, and
> nearly nasty: you can do that directly via a video driver for qemu,
> and moreover it will let you far more control over qemu.
> Pierre.

reply via email to

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