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

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

[Miguel Angel Fraile]

Christian MICHON wrote:
> yes, but this is only for windows hosts, and you must install
> visual basic.

Yes, this is only for windows hosts, but you don't need VB at all, as
there are other frontend not written on VB that would benefit from
this patch (like QEMU Manager: http://www.davereyn.co.uk/qemu ).

> wouldnt' it be better to add an extra sdl "console" (today we've
> main window, control, serial, parallel) where we could set parameters
> graphically ? or at least as a text form to read a cfg file ?

I would like to see an integrated frontend, but there are some
problems as written on this thread.

> this would pay more than to have 1 frontend for windows, 1 for linux,
> 1 for sparc, 1 for mac, etc...
>
> what's your opinion on this ?

I would add a modular frontend on QEmu. I mean, there should be one
general module that creates the GUI itself (frontend.c) using
functions written on a system-specific module (frontend-<system>.h).

In example:
frontend.c
frontend-windows.h
frontend-linux.h
frontend-macos.h

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

[Sylvain Petreolle]

--- Christian Bourque <christian.bourque@gmail.com> a écrit:
> Christian MICHON wrote:
> >this would pay more than to have 1 frontend for windows, 1 for linux,
> >1 for sparc, 1 for mac, etc...
> >what's your opinion on this ?
> 
> You could also use my frontend JQEMU which works on any Java enabled platform :)
> 
> Christian
If you want to say its "totally free and distributed under the terms of the GPL", 
PLEASE provide the sources anywhere you can...

Kind regards,

Usurp (aka Sylvain Petreolle)

humans are like computers,
yesterday the BIOS was all
- today its just a word

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

[Christian Bourque]

Christian MICHON wrote:
>this would pay more than to have 1 frontend for windows, 1 for linux,
>1 for sparc, 1 for mac, etc...
>what's your opinion on this ?

You could also use my frontend JQEMU which works on any Java enabled platform :)

Christian

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

[Christian MICHON]

how much disk space is needed for qemu itself, and for a basic JRE.
The size difference is around 30x to 50x.

But I'll try the JQEMU tomorrow :)

Christian

On 5/26/05, Christian Bourque <christian.bourque@gmail.com> wrote:
> Christian MICHON wrote:
> >this would pay more than to have 1 frontend for windows, 1 for linux,
> >1 for sparc, 1 for mac, etc...
> >what's your opinion on this ?
> 
> You could also use my frontend JQEMU which works on any Java enabled platform :)
> 
> Christian
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 


-- 
Christian

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

[Jerome Warnier]

Le jeudi 26 mai 2005 à 11:14 -0400, Christian Bourque a écrit :
> Christian MICHON wrote:
> >this would pay more than to have 1 frontend for windows, 1 for linux,
> >1 for sparc, 1 for mac, etc...
> >what's your opinion on this ?
> 
> You could also use my frontend JQEMU which works on any Java enabled platform :)
Is it available somewhere?

> Christian
-- 
Jerome Warnier <jwarnier@beeznest.net>
BeezNest

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

[Miguel Angel Fraile]

Hi,

I'm the author of QGui, a windows frontend for QEmu available at
http://perso.wanadoo.es/comike.

I've been trying to attach the QEmu screen to my frontend, but I
finally realized I needed to modify QEmu source to get it.

So I've attached a patch that adds a "-hwnd <handle>" argument to QEmu.

<handle> refers to the window handle where QEmu should be embedded (it
can be any control like a groupbox, form, etc).

Then, QEmu creates a new window that has the window specified at
command-line as parent. If QEmu screen size changes, parent and child
windows are resized automatically.

I hope the patch can be applied to CVS, as it would be very useful for
frontend authors.

PS: Please, add my mail address on CC, as I'm not subscribed to this list.

------------------------------------
--- vl.c Thu May 26 11:04:04 2005
+++ vl.c.new Thu May 26 11:03:34 2005
@@ -150,6 +150,9 @@
#ifdef TARGET_I386
int win2k_install_hack = 0;
#endif
+#ifdef _WIN32
+HWND fend_hwnd, qemu_hwnd;
+#endif

/***********************************************************/
/* x86 ISA bus support */
@@ -2785,6 +2788,9 @@
            "-serial dev     redirect the serial port to char device 'dev'\n"
            "-parallel dev   redirect the parallel port to char device 'dev'\n"
            "-pidfile file   Write PID to 'file'\n"
+#ifdef _WIN32
+           "-hwnd handle embed QEmu inside a custom window"
+#endif
            "-S              freeze CPU at startup (use 'c' to start
execution)\n"
            "-s              wait gdb connection to port %d\n"
            "-p port         change gdb connection port\n"
@@ -2883,6 +2889,7 @@
     QEMU_OPTION_loadvm,
     QEMU_OPTION_full_screen,
     QEMU_OPTION_pidfile,
+ QEMU_OPTION_hwnd,
     QEMU_OPTION_no_kqemu,
     QEMU_OPTION_win2k_hack,
};
@@ -2953,6 +2960,9 @@
     { "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
     { "full-screen", 0, QEMU_OPTION_full_screen },
     { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
+#ifdef _WIN32
+ { "hwnd", HAS_ARG, QEMU_OPTION_hwnd },
+#endif
     { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
     
     /* temporary options */
@@ -3036,7 +3046,13 @@
     char parallel_devices[MAX_PARALLEL_PORTS][128];
     int parallel_device_index;
     const char *loadvm = NULL;
-    
+
+#ifdef _WIN32
+ char widbuf[24];
+ fend_hwnd=NULL;
+ qemu_hwnd=NULL;
+#endif
+
#if !defined(CONFIG_SOFTMMU)
     /* we never want that malloc() uses mmap() */
     mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
@@ -3405,6 +3421,16 @@
             case QEMU_OPTION_pidfile:
                 create_pidfile(optarg);
                 break;
+#ifdef _WIN32
+ case QEMU_OPTION_hwnd:
+ fend_hwnd=(HWND)atoi(optarg);
+ qemu_hwnd=CreateWindow("BUTTON",NULL,BS_OWNERDRAW | WS_CHILD |
+ WS_VISIBLE,0,0,700,420,fend_hwnd,NULL,
+ GetModuleHandle(NULL),NULL);
+ sprintf(widbuf,"SDL_WINDOWID=%#x",(long)qemu_hwnd);
+ putenv(widbuf);
+ break;
+#endif
#ifdef TARGET_I386
             case QEMU_OPTION_win2k_hack:
                 win2k_install_hack = 1;
--- sdl.c Thu May 26 11:03:50 2005
+++ sdl.c.new Thu May 26 11:03:44 2005
@@ -27,6 +27,9 @@

#ifndef _WIN32
#include <signal.h>
+#else
+#include <windows.h>
+extern HWND fend_hwnd,qemu_hwnd;
#endif

static SDL_Surface *screen;
@@ -66,6 +69,12 @@
     ds->depth = screen->format->BitsPerPixel;
     ds->width = w;
     ds->height = h;
+#ifdef _WIN32
+ SetWindowPos(qemu_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+ SetWindowPos(fend_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+#endif
}

/* generic keyboard conversion */
@@ -258,6 +267,9 @@
     if (gui_grab) {
         strcat(buf, " - Press Ctrl-Alt to exit grab");
     }
+#ifdef _WIN32
+ if (qemu_hwnd!=NULL)
+#endif
     SDL_WM_SetCaption(buf, "QEMU");
} 
-----------------------------------

Best regards.
Míguel

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

[Christian MICHON]

yes, but this is only for windows hosts, and you must install
visual basic.

wouldnt' it be better to add an extra sdl "console" (today we've
main window, control, serial, parallel) where we could set parameters
graphically ? or at least as a text form to read a cfg file ?

this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...

what's your opinion on this ?

Christian

On 5/26/05, Miguel Angel Fraile <mianfrar@gmail.com> wrote:
> Hi,
> 
> I'm the author of QGui, a windows frontend for QEmu available at
> http://perso.wanadoo.es/comike.
>

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

[Oliver Gerlich]

Christian MICHON wrote:
> yes, but this is only for windows hosts, and you must install
> visual basic.
> 
> wouldnt' it be better to add an extra sdl "console" (today we've
> main window, control, serial, parallel) where we could set parameters
> graphically ? or at least as a text form to read a cfg file ?
> 
> this would pay more than to have 1 frontend for windows, 1 for linux,
> 1 for sparc, 1 for mac, etc...
> 
> what's your opinion on this ?
> 
> Christian
> 
> On 5/26/05, Miguel Angel Fraile <mianfrar@gmail.com> wrote:
> 
>>Hi,
>>
>>I'm the author of QGui, a windows frontend for QEmu available at
>>http://perso.wanadoo.es/comike.
>>
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

I think Miguels patch is quite useful. It makes it possible to use 
native Windows controls and Windows API calls to display a nice GUI for 
Qemu, without adding much code to Qemu itself. Actually I've been 
working on something similar for XFree (with XEmbed) to embed Qemu into 
a GUI written with Perl and GTK :) (it partially works already, but 
focusing and mouse grabbing doesn't work quite well yet). Btw. I 
remember at least two people working on this XEmbed thing as well.
IMHO adding a GUI built with SDL would be much more difficult than using 
native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX 
GUI in the end?
However, the disadvantage of the "native GUI" approach might be that 
lots of different GUIs appear, instead of a graphical interface which is 
basically consistent on all platforms (like VMWare for Linux is 
basically consistent with VMWare for Windows, although both use 
different GUI toolkits).

My conclusion is that there should be a discussion (or simply a 
decision) on how to build a GUI for Qemu, and that embedding Qemu into 
native GUIs could be a good way :)

Oliver Gerlich

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

[Christian MICHON]

> I think Miguels patch is quite useful. It makes it possible to use
> native Windows controls and Windows API calls to display a nice GUI for
> Qemu, without adding much code to Qemu itself. Actually I've been
> working on something similar for XFree (with XEmbed) to embed Qemu into
> a GUI written with Perl and GTK :) (it partially works already, but
> focusing and mouse grabbing doesn't work quite well yet). Btw. I
> remember at least two people working on this XEmbed thing as well.
> IMHO adding a GUI built with SDL would be much more difficult than using
> native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX
> GUI in the end?

All of these are very useful patches indeed. But there's at least 4 gui toolkit
available for SDL, which could ensure:

- a single developpement and a uniform look
- no need for a bigger space on screen (the controls could be like OSD)
- independent of hw/os architecture (the original aim somehow of qemu?)

I agree this is poking inside qemu itself, which can be considered
"a bad thing" (tm). I'm looking at the 4 gui toolkits I mentionned.

- http://www.paragui.org/
- http://guichan.sourceforge.net/
- http://agar.csoft.org/index.html.en
- http://aedgui.sourceforge.net/

Let's open the discussion in a separate thread.

Christian

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

[Fabrice Bellard]

Christian MICHON wrote:
> yes, but this is only for windows hosts, and you must install
> visual basic.
> 
> wouldnt' it be better to add an extra sdl "console" (today we've
> main window, control, serial, parallel) where we could set parameters
> graphically ? or at least as a text form to read a cfg file ?
> 
> this would pay more than to have 1 frontend for windows, 1 for linux,
> 1 for sparc, 1 for mac, etc...
> 
> what's your opinion on this ?

As I said earlier, I would prefer to integrate the GUI in QEMU like the 
cocoa.m implementation. GTK for Linux is the best option. For Windows, 
either GTK or a native GUI usage would be possible, depending on the 
reliability of the GTK port for Windows.

Fabrice.

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

[Christian MICHON]

Hi Fabrice,

I understand your point clearly, and I still remembered it.
But adding whichever toolkit would be adding pixels around the
qemu instance, and it would have to interact with SDL.

My simple logic here is why not do it in SDL itself, like an
OSD you'd call by bindkey, like a TV remote control ?

I do not know what cocoa.m implementation is, but I've seen
screenshots. It does require space, and if you go full-screen,
you can't do modifications. Hence the suggestion to go
full SDL.

I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting
stuff they can do... :)

> As I said earlier, I would prefer to integrate the GUI in QEMU like the
> cocoa.m implementation. GTK for Linux is the best option. For Windows,
> either GTK or a native GUI usage would be possible, depending on the
> reliability of the GTK port for Windows.
> 
> Fabrice.
> 


-- 
Christian

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

[Fabrice Bellard]

Christian MICHON wrote:
> Hi Fabrice,
> 
> I understand your point clearly, and I still remembered it.
> But adding whichever toolkit would be adding pixels around the
> qemu instance, and it would have to interact with SDL.
> 
> My simple logic here is why not do it in SDL itself, like an
> OSD you'd call by bindkey, like a TV remote control ?
> 
> I do not know what cocoa.m implementation is, but I've seen
> screenshots. It does require space, and if you go full-screen,
> you can't do modifications. Hence the suggestion to go
> full SDL.
> 
> I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting
> stuff they can do... :)

Improving the SDL interface is a waste of time as SDL has some annoying 
bugs and cannot give a good GUI for the end user. Doing a native GTK or 
Windows GUI is not complicated and would bring much more confort to the 
end user.

Fabrice.

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

[Pierre d'Herbemont]

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.

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

[Christian MICHON]

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
mode.

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". :)
Christian


On 5/27/05, Pierre d'Herbemont <stegefin@free.fr> 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.
>

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

[Oliver Gerlich]

Christian MICHON wrote:
> 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
> mode.
> 
> 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". :)
> Christian
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Coming to think of it, I happen to like the idea of an OSD :) . Although 
I use Qemu mostly in windowed mode with 1024x786 on a 1280x1024 screen 
(windowed mode is nice for having Visual Studio in Qemu and Mozilla 
Browser with MSDN under Linux), there are situations where fullscreen 
mode is better. And in these cases a little OSD would be nice, with 
buttons to change CDs, suspend the guest, stop the guest, and maybe 
seeing the current guest CPU load and guest HDD activity. Maybe the OSD 
should be similar to the little top bar in Windows Terminal Server 
connections (IIRC it makes it possible to get out of from fullscreen mode).
As such, an OSD in addition to the GUI would be really useful I think.

Just my two cents,
Oliver Gerlich

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

[Joe Batt]

On Sat, 2005-05-28 at 16:10 +0200, Oliver Gerlich wrote:
> Christian MICHON wrote:
> > ...
> Coming to think of it, I happen to like the idea of an OSD :) ...

For reference, I work 30 hrs/wk in a VMWare VM running w2k on a Linux
workstation.  I keep my left screen in X for local apps, but the right
screen is in "Quick Switch" mode, which is essentially full screen mode,
but when I push the top of the screen, I get the VMWare menu.  I really
like this mode.

I would switch to qemu (even pay for it), if supported multiple CPUs and
IO performance was better.  I am an application developer and run
Eclipse (sucks memory) and compilers (uses lots of IO).

(For reference, VMWare doesn't support multiple CPUs for a reasonable
price and IO is better than qemu, but is still bad.)

-- 
Joe Batt <Joe@soliddesign.net>

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

[Jernej Simončič]

On Thursday, May 26, 2005, 22:03:31, Fabrice Bellard wrote:

> As I said earlier, I would prefer to integrate the GUI in QEMU like the
> cocoa.m implementation. GTK for Linux is the best option. For Windows, 
> either GTK or a native GUI usage would be possible, depending on the 
> reliability of the GTK port for Windows.

GTK+ on Windows is stable, and even though it doesn't officially support the
Win98/ME anymore, it works on those OSes, too (recently, some bugs that
prevented it working there were fixed; it doesn't work on Windows 95
though).

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

It won't work.
       -- Jenkinson's Law