Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
--- Christian Bourque [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 [EMAIL PROTECTED] 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
