Re: [Qemu-devel] quick gtk2.c update
Jm C. Brown This should be fixed now. (At least, this now works in Windows 98 and XP.) I managed to combine the 3 separate mouse handlers into a single function as well, so there is less redundant code. It does appear to be fixed. Also, I managed to get rid of the all of the GTK warnings. That's always good. Although this time I didn't watch it build to see if there were any new ones. There *is* still an insert key problem. I tested it under Win3, Win95 and Win98 That's the only key I've noticed that still has problems. But I may not have tested them all, so I might have missed one or two others. When I run the gtk version from the qgui program (which just lets you select which VM, what options etc., and then runs it) the qemu window doesn't pop up as visible. I have to clcik on its title on the task bar to bring it forward. Probably needs a command to bring it into 'focus' or some such. Most fullscreen glitches are gone now. (The only one left is that, if you change I haven't really tested that much... Under Win95 guest it doesn't really go 'full screen'. It's a borderless window. That could be due to Win95 being in 640x480 mode and my real screen is larger? Let me run a couple of tests with Win98. (Win95 seems to have problems with the qemu cirrus card, but that could be due to it being a 'dirty' install.) Okay, it looks like the full screen mode has problems. First, it doesn't really go 'full screen'. It just makes a borderless window. That means you can't use a guest window the same size as the host, otherwise the host XP toolbar will cover up part of the guest window. (XP's toolbar can be on any side of the screen. There can even be multiple toobars. So you really can't depend on having any certain amount of visible screen available.) As a test, I decided to see what would happen if I made Win98's screen larger than what my real one is. The results were interesting! Naturally I couldn't see most of it. After all, you haven't yet done any scrollbars or scaling of the window. (Actually, scroll bars would be nice, but if you can scale the window, then the guest could think you are using any size while everything is still fiting nicely into the host window. That could even let you resize the qemu screen to any size you want, and let the gtk driver resize the display as needed.) The interesting part was the mouse behavior! I ended up with *two* mouse cursors on the screen. And they weren't moving quite right. I couldn't move the guest Win98 one where I needed to. I don't know if this was a gtk issue, or a Windows host issue Let me go try that with the 0.70 SDL build Hmmm... I can't get it to do it there. But I'm not entirely sure of the exact steps I did to cause it under GTK. And of course, the SDL version crashes when I try full screen. Let me try it again with the GTK build... This time, I didn't even test the full screen mode (since you said it does still have problems.). But, I definetly have mouse problems. After I switched to a screen larger than my real screen, I couldn't move the mouse much. It was very limited amount of movement. Much less than the visible part of the qemu screen was. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Mon, Jun 27, 2005 at 12:11:10PM -0500, [EMAIL PROTECTED] wrote: This should be fixed now. (At least, this now works in Windows 98 and XP.) I managed to combine the 3 separate mouse handlers into a single function as well, so there is less redundant code. It does appear to be fixed. Excellent. Also, I managed to get rid of the all of the GTK warnings. That's always good. Although this time I didn't watch it build to see if there were any new ones. I meant the GTK warnings that appear at run time (the assert failed warnings). I've never gotten GTK warnings when building a working version...but I've never built under Windows either. There *is* still an insert key problem. I tested it under Win3, Win95 and Win98 That's the only key I've noticed that still has problems. But I may not have tested them all, so I might have missed one or two others. Did you test with Windows 98SE? Windows 98SE has no issues with the insert key when running under GTK in Linux.. which would mean the problem is with VK_INSERT. When I run the gtk version from the qgui program (which just lets you select which VM, what options etc., and then runs it) the qemu window doesn't pop up as visible. I have to clcik on its title on the task bar to bring it forward. Probably needs a command to bring it into 'focus' or some such. Most fullscreen glitches are gone now. (The only one left is that, if you change I should have been clearer. The glitches that I fixed were for the Xvid fullscreen driver. Windows build still uses the null fullscreen driver. I haven't really tested that much... Okay, it looks like the full screen mode has problems. First, it doesn't really go 'full screen'. It just makes a borderless window. Thats to be expected with the null fullscreen driver. qemu's GTK support expects the fullscreen driver to change the resolution of the host to match that of the guest (that way the window will take up the entire screen). I'm working on an SDL fullscreen driver, but it is uglier. (It'd require usurping the internal DisplayState structure and replace the GTK routines with custom SDL versions for the duration of fullscreen mode Exiting fullscreen mode would then have to restore the GTK routines. Not to mention syncing the 2 frame buffers between switches.) That means you can't use a guest window the same size as the host, otherwise the host XP toolbar will cover up part of the guest window. (XP's toolbar can be on any side of the screen. There can even be multiple toobars. So you really can't depend on having any certain amount of visible screen available.) I never thought about that. Does the XP toolbar show up when using SDL's fullscreen mode? As a test, I decided to see what would happen if I made Win98's screen larger than what my real one is. The results were interesting! The interesting part was the mouse behavior! I ended up with *two* mouse cursors on the screen. That is weird. I've seen that once before, when the pointer grab failed (because the host pointer was outside the GTK window) but then GDK later grabbed it anyways. When it did the grab, it failed to render the host pointer invisible. The effect was a swirling mouse in the middle of the guest screen. And they weren't moving quite right. I couldn't move the guest Win98 one where I needed to. This is expected behavior. Currently the GTK code assumes that the entire window fits in a single screen. When it grabs the mouse (and after it renders the mouse invisible), it confines the pointer to an area in the very middle of the window that is approximately half the size of the full area of the window. When the host pointer hits the border of this inner area, it is wrapped to the other side. Because the GTK window was larger than the screen, when the host pointer hit the edge of the screen it wouldn't be able to move any more .. which means the guest pointer wouldn't be able to either. Even if it was at the top corner of the window. I don't know if this was a gtk issue, or a Windows host issue It's really a hack around a GDK limitation. This time, I didn't even test the full screen mode (since you said it does still have problems.). But, I definetly have mouse problems. After I switched to a screen larger than my real screen, I couldn't move the mouse much. It was very limited amount of movement. Much less than the visible part of the qemu screen was. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Christian Bourque wrote: Hi Jim! Could you send a new Makefile.diff (the old one is not working with the latest cvs version of QEMU), I would like to test this code too... I had huge rejects in Makefile.target, configure and vl.h. I merged them by hand and used the latest gtk2.c and xid_fs.c files I could find on the list.. It works great here on linux anyway. Good job Jim! Regards, Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Mon, Jun 27, 2005 at 05:19:17PM -0400, Christian Bourque wrote:
Hi Jim!
Could you send a new Makefile.diff (the old one is not working with
the latest cvs version of QEMU), I would like to test this code too...
Thanks
Christian
I just tested it myself. This patch was applied to latest CVS and it worked
perfectly. (The CVS was pure btw - freshly checked out into a new directory.)
If there are any rejects with this, please email the *.rej files to me.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
diff -u qemu.orig/vl.c qemu/vl.c
--- qemu.orig/vl.c Tue May 31 14:53:22 2005
+++ qemu/vl.c Tue May 31 14:52:55 2005
@@ -147,6 +147,7 @@
TextConsole *vga_console;
CharDriverState *serial_hds[MAX_SERIAL_PORTS];
CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
+int use_gtk = 0;
#ifdef TARGET_I386
int win2k_install_hack = 0;
#endif
@@ -2877,6 +2878,7 @@
QEMU_OPTION_cirrusvga,
QEMU_OPTION_g,
QEMU_OPTION_std_vga,
+QEMU_OPTION_use_gtk,
QEMU_OPTION_monitor,
QEMU_OPTION_serial,
QEMU_OPTION_parallel,
@@ -2947,6 +2949,7 @@
{ localtime, 0, QEMU_OPTION_localtime },
{ isa, 0, QEMU_OPTION_isa },
{ std-vga, 0, QEMU_OPTION_std_vga },
+{ use-gtk, 0, QEMU_OPTION_use_gtk },
{ monitor, 1, QEMU_OPTION_monitor },
{ serial, 1, QEMU_OPTION_serial },
{ parallel, 1, QEMU_OPTION_parallel },
@@ -3345,6 +3348,9 @@
case QEMU_OPTION_std_vga:
cirrus_vga_enabled = 0;
break;
+case QEMU_OPTION_use_gtk:
+use_gtk = 1;
+break;
case QEMU_OPTION_g:
{
const char *p;
@@ -3599,7 +3605,17 @@
if (nographic) {
dumb_display_init(ds);
} else {
+#if defined(CONFIG_GTK)
#if defined(CONFIG_SDL)
+ /* so we can choose */
+ if (use_gtk)
+gtk2_display_init(ds, full_screen);
+ else
+sdl_display_init(ds, full_screen);
+#else
+gtk2_display_init(ds, full_screen);
+#endif
+#elif defined(CONFIG_SDL)
sdl_display_init(ds, full_screen);
#elif defined(CONFIG_COCOA)
cocoa_display_init(ds, full_screen);
diff -u qemu.orig/Makefile.target qemu/Makefile.target
--- qemu.orig/Makefile.target Mon May 30 19:42:28 2005
+++ qemu/Makefile.targetMon May 30 19:57:26 2005
@@ -357,6 +357,10 @@
ifdef CONFIG_SDL
VL_OBJS+=sdl.o
endif
+ifdef CONFIG_GTK
+VL_OBJS+=gtk2.o
+VL_OBJS+=fullscreen.o
+endif
ifdef CONFIG_COCOA
VL_OBJS+=cocoa.o
COCOA_LIBS=-F/System/Library/Frameworks -framework Cocoa
@@ -392,13 +396,19 @@
endif
$(QEMU_SYSTEM): $(VL_OBJS) libqemu.a
- $(CC) $(VL_LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(VL_LIBS)
+ $(CC) $(VL_LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
$(GTK_LIBS) $(FS_LIBS) $(VL_LIBS)
cocoa.o: cocoa.m
$(CC) $(CFLAGS) $(DEFINES) -c -o $@ $
sdl.o: sdl.c keymaps.c sdl_keysym.h
$(CC) $(CFLAGS) $(DEFINES) $(SDL_CFLAGS) -c -o $@ $
+
+gtk2.o: gtk2.c keymaps.c gdk_keysym.h fullscreen.h
+ $(CC) $(CFLAGS) $(DEFINES) $(GTK_CFLAGS) -c -o $@ $
+
+fullscreen.o: $(FSDRV) fullscreen.h
+ $(CC) $(CFLAGS) $(DEFINES) -c -o $@ $
sdlaudio.o: sdlaudio.c
$(CC) $(CFLAGS) $(DEFINES) $(SDL_CFLAGS) -c -o $@ $
diff -u qemu.orig/configure qemu/configure
--- qemu.orig/configure Mon May 30 19:40:14 2005
+++ qemu/configure Mon May 30 20:10:11 2005
@@ -15,6 +15,7 @@
TMPO=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.o
TMPE=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}
TMPS=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.S
+TMPF=${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}-conf
# default parameters
prefix=
@@ -171,6 +172,10 @@
;;
--disable-sdl) sdl=no
;;
+ --enable-gtk) gtk=yes
+ ;;
+ --set-fs-driver=*) fsdrv=`echo $opt | cut -d '=' -f 2`
+ ;;
--enable-fmod) fmod=yes
;;
--fmod-lib=*) fmod_lib=${opt#--fmod-lib=}
@@ -311,6 +316,62 @@
fi # cross compilation
fi # -z $sdl
+##
+# GTK probe
+
+gtk_too_old=no
+
+if test -z $gtk ; then
+
+gtk=no
+
+# normal GTK probe
+cat $TMPC EOF
+#include stdlib.h
+#include gtk/gtk.h
+int main(int argc, char **argv) { gtk_init(argc, argv); return EXIT_SUCCESS;
}
+EOF
+
+if $cc -o $TMPE `pkg-config --cflags --libs gtk+-2.0 2 /dev/null` $TMPC 2
/dev/null ; then
+_gtkversion=`pkg-config --modversion gtk+-2.0 | sed 's/[^0-9]//g'`
+if test $_sdlversion -lt 240 ; then
+ gtk_too_old=yes
+else
+ gtk=yes
+
+fi
+
+fi # gtk compile test
+
+fi # -z $gtk
+
+if [ $gtk = yes ]; then
+
+if [ $fsdrv = ] ; then
+
+if [ $bsd = yes -o $linux = yes ]; then
+ fsdrv=xvid_fs.c
+else
+ fsdrv=null_fs.c
+fi
+
+fi # fsdrv test
+
+if [ $fsdrv = xvid_fs.c -o $fsdrv = null_fs.c ]; then
+ echo fsdrv=$fsdrv $TMPF
+else
+ echo Warning: unknown gtk fullscreen driver: $fsdrv - using null driver
+ echo 'fsdrv=null_fs.c' $TMPF
+ fsdrv=null_fs.c
+fi
+
+if [ $fsdrv = xvid_fs.c
Re: [Qemu-devel] quick gtk2.c update
On Wed, Jun 22, 2005 at 09:26:11PM -0500, [EMAIL PROTECTED] wrote:
Now, while running my Win 3 test image, I notice that double clicking
doesn't work. I couldn't get anything to open up no matter how fast I
clicked.
This should be fixed now. (At least, this now works in Windows 98 and XP.) I
managed to combine the 3 separate mouse handlers into a single function as well,
so there is less redundant code.
Also, I managed to get rid of the all of the GTK warnings.
Most fullscreen glitches are gone now. (The only one left is that, if you change
video modes in the guest while in fullscreen mode, the window might move around
randomly. For now, switching out of fullscreen and then back in will set things
right again.)
New gtk2.c attached.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/*
* QEMU GTK2 display driver
* based on SDL driver by Fabrice
*
* Copyright (c) 2005 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include vl.h
#include gtk/gtk.h
#include gdk/gdk.h
#include fullscreen.h
/* define our own bitshift enums to allow qemugtk to know difference between
left and right alt - something gtk doesnt provide in its modifiers mask. this
uses qemu's own modifier_state[] map in order to guess correctly */
typedef enum
{
gtkshiftleft = 1 0,
gtkshiftright = 1 1,
gtkcontrolleft = 1 2,
gtkcontrolright = 1 3,
gtkaltleft = 1 4,
gtkaltright = 1 5,
gtkcapslock = 1 6
} gtk2keymod;
static GtkWidget *screen;
static GdkImage *image=NULL;
static GdkCursor *invisible_cursor;
static int ox = 0, oy = 0;
static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
static int last_vm_running;
static int gui_saved_grab;
static int gui_fullscreen;
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
static int gui_grab_code = gtkaltleft | gtkcontrolleft;
static uint8_t modifiers_state[256];
static unsigned int cw, ch;
static gint cx, cy;
static gboolean gtk2_expose(GtkWidget *wid, GdkEventExpose *event)
{
gdk_draw_image(wid-window, wid-style-fg_gc[GTK_WIDGET_STATE(wid)],
image, event-area.x, event-area.y, event-area.x, event-area.y,
event-area.width, event-area.height);
return TRUE;
}
static void gtk2_update(DisplayState *ds, int x, int y, int w, int h)
{
//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
GdkEventExpose ev;
ev.area.x = x;
ev.area.y = y;
ev.area.width = w;
ev.area.height = h;
/* catch the first resize done by the init function - make sure we don't **
** try to draw an image until screen has been finalized/realized/etc */
if (screen-window != NULL)
gtk2_expose(screen, ev);
}
static void gtk2_resize(DisplayState *ds, int w, int h)
{
//printf( resizing to %d %d\n, w, h);
if (gui_fullscreen)
{
if (cw != w || ch != h)
{
fullscreen_switch(cx, cy, w, h); /* changing video modes */
/* apparently GTK enjoys moving static windows all over the place while
they are being resized - so we have to be tricky */
gtk_window_move(GTK_WINDOW(screen), cx, cy);
gtk_window_move(GTK_WINDOW(screen), 0, 0);
}
}
cw = w; ch = h;
if (image)
g_object_unref(image);
/* gdk_visual_get_best_with_depth() ??? but then how to paint onto window? */
image = gdk_image_new(GDK_IMAGE_NORMAL, gdk_visual_get_system(), w, h);
gdk_image_set_colormap(image, gdk_colormap_get_system());
gtk_window_set_default_size(GTK_WINDOW(screen), w, h);
gtk_widget_set_size_request(screen, w, h);
gtk_window_resize(GTK_WINDOW(screen), w, h);
ds-data = image-mem;
ds-linesize = image-bpl;
ds-depth = image-bits_per_pixel;
ds-width = w;
ds-height = h;
gtk2_update(ds, 0, 0, w, h);
}
/* generic keyboard conversion */
#include gdk_keysym.h
#include keymaps.c
Re: [Qemu-devel] quick gtk2.c update
On Wed, Jun 22, 2005 at 09:26:11PM -0500, [EMAIL PROTECTED] wrote: Jim C. Brown Ok this is probably the final revision. I had the code vindicated by an actual Windows programmer. He says it should work fine. It should compile, run, and make Okay... I compiled it and the keys do appear to work. That problem does appear to be fixed. Excellent news. It doesn't look like the 'insert' key toggles between insert / overstrike when I use the Win3 wordpad to read a file. However, this is in the regular qemu 0.70, so I don't know if it's a problem with qemu, or Win 3 wordpad. I don't have a copy of Windows 3 (3.0, 3.1, WfW, or 3.11), so I am not able to test this. Windows 98 Wordpad has no issues with the insert key for qemu-gtk. Now, while running my Win 3 test image, I notice that double clicking doesn't work. I couldn't get anything to open up no matter how fast I clicked. Single clicking works okay, though. Again, I can't test Windows 3. However, under Windows 98 double clicking does seem to have problems. It does work for me ocassionally (if I keep clicking hard and fast enough - more stream clicking than double clicking), but there are clear issues. The way GTK/GDK deals with single, double, and triple clicks is weird. I'll take a much closer look at it. qemu under gtk usable. Also I modified it so it lets u know when u are using GTK. I noticed that immediately when I ran it... Nice. Thanks. Never a problem. Like I said, it was a dumb oversight on my part. Still, I work with what I have to go on. Try this gtk2.c and report any errors (be they compile errors or runtime errors or keyboard problems). Your help is always greatly appreciated. I'm glad I'm able to help. The previous qemu errors I've reported have been completely ignored! At least you are taking an active interest in what a mere user has to say I don't think that I am exceptional in this. Most developers are happy to fix bugs that users report (time permitting of course). It simply looks like qemu is lacking dedicated Windows developers. At least, thats how it looks to me. I know of only 1 real developer of qemu under windows. But he works on a separate tree (C code cleaned up to compile under MSVC, different IDE and VGA/ Cirrus code, etc). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Wednesday, June 22, 2005, 1:58:14, Jim C. Brown wrote: GTK libraries are not part of qemu, they are a separate resource that qemu depends on. As far as the user is concerned, they are part of qemu. I must disagree here. If a user already has xchat 2 installed, and that person wants to try to use qemu with the GTK interface, they already have the libraries that they need. Be careful with Xchat, some versions link to modified static GTK+, and a few of them install GTK+ to it's own directory. Problem here is, that there's no standarised installer for GTK+ - Tor only provides zipfiles, and it's up to the developers how they use these ZIPs. Hopefully this will change when porting of Evolution to Windows will be completed. It's a very bad idea to have the installer need to go back on to the net to download something else. The user should get the whole thing at once. Many installers for Windows GTK+ programs do this, and nobody has a problem with it. You could also make a ZIP file that includes both installers, and if the user tries to install Qemu without the GTK+ libraries, the GTK+ installer could be automatically invoked in silent mode (this is what I plan for the Gimp). I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a good solution for that. It's Common Files\GTK\2.0 actually, since GTK+ 1.3 can also be installed there. -- Jernej Simoncic http://deepthought.ena.si/ Whenever you cut your fingernails, you will find a need for them an hour later. -- Witten's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Wednesday, June 22, 2005, 6:14:50, [EMAIL PROTECTED] wrote: Like those files actually might possibly ever get used by some other app. Not too likely for a Windows user. There's quite a selection of GTK+ programs for Windows available - Gimp, Xchat, Gaim, Ethereal, ... BTW, it doesn't necesarily have to be Common Files\GTK\2.0, it can be any directory as long as it's stored in registry in HKEY_LOCAL_MACHINE\Software\GTK\2.0\Path - this is the key you should check to see if GTK+ is installed. That GTK website specifically mentions that certain versions are broken for Windows. The only broken versions of GTK+ in the last few years were 2.6.2-2.6.4, and only on Windows 98/ME (Windows 95 isn't supported anymore, and even 98/ME aren't officially supported, since none of the developers has them installed). By bundling the libraries with qemu, and keeping them in the qemu directory, you can guarantee that the user has versions that work right and are compatible with qemu. No -mms-whatever struct issue or anything else. The only way you'd get GTK+ libraries that wouldn't be compiled with -mms-bitfields would be to compile them yourself after modifying configure script to not automatically include it. -- Jernej Simoncic http://deepthought.ena.si/ A good plan today is better than a perfect plan tomorrow. -- Patton's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 11:14:50PM -0500, [EMAIL PROTECTED] wrote: They should only get this library if they don't already have a copy installed. Which will be practically every qemu user. [ Technically not true. Most qemu users are Linux users, and most Linux users have GTK. :) Sorry, I couldn't resist. ] All your other arguments about GTK basicly break down to this. If only qemu wants GTK, then your arguments make sense. However, if there are a lot of users which use other GTK applications besides qemu, then your arguments do not apply. A standard Joe Schmoe Windows user probably would not know what GTK is or ever even hear the name mentioned. That user would have little if any FOSS software and may not even be aware about FOSS in general. I won't argue about using xchat, gaim, evolution, etc for this user. The person probably bought all the applications that this person would ever use. This person is also unlikely to need to run multiple OSes at once, and even if this person did, the product used would probably be VMware or Virtual PC or some other commercial product. Certainly not qemu, which AFAIK lacks corporate backing or commercial support (unlike Linux which has dozens of companies funding development and offering support). I am not saying that this can't change. I'm also not arguing against trying to change this. I'm just saying that GTK vs no-GTK doesn't make a difference here for qemu. A Windows user who does use qemu will probably be very familar with OSS software. That user may scoff at high priced programs and get software that is just as good for free. That user may run Evolution instead of Outlook, gaim instead of AIM Messenger, etc. That user will probably have GTK installed. I realise that these two examples represent extremes of a continum, and that more users better fit the first example. However, GTK is more well known than qemu is, and one of GTK 2's goals is to be portable and easy to use on Windows. By bundling the libraries with qemu, and keeping them in the qemu directory, you can guarantee that the user has versions that work right and are compatible with qemu. No -mms-whatever struct issue or anything else. No, that will always be an issue. But my latest patch fixed it, so qemu windows users at least shouldn't see it anymore. There is no GUI yet. I could easily make a crappy one in, say, 20 minutes. It'd work fine, but it may not be a lot of fun to use. For that matter, it may not be that useful. Well, maybe not 'gui', but something that tells the user they are indeed running the GTK version and not the SDL version. You're right, thats probably a good idea. On linux, you get some GTK warnings in the console - so its pretty clear if you are using GTK or not. That's my excuse. ;D How would you like me to fix this? Alter the title of the window so it says Qemu GTK ? Show that GTK is on in the monitor interface, maybe an info gtk that returns if gtk is on or not and what version is being used? -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 07:58:14PM -0400, Jim C. Brown wrote:
Well, no, that isn't it. The keymap files are based on X11 keycodes, so even
if
you could use this option it wouldn't work at all.
More digging around in sdl.c revealed that SDL on Linux returns X11 keycodes
as GTK on Linux does, while on Windows SDL returns the raw scan code.
I know the offending function. This is the culprit:
static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev)
Apparently, that does not work for win32 gtk.
In fact, that is apparently the Windows virtual key code, not the raw
scancode.
Hence the funny characters. The good news is that this is an easy fix.
I've cleaned up the code a little bit, and attached a new gtk2.c to this email.
What I really need is a Win32
programmer to proofread this, make sure I got it right.
Since no Win32 person on this list or in the qemu irc channel offered to help
me,
I can not even guarrentee this will compile. And if it does compile, it is
possible
that keys will not work right due to lost of information due to casting (this is
unlikely as all scancodes can be represented as a single byte, and it seems all
Windows virtual key codes can be represented in at least two bytes).
Still, I work with what I have to go on. Try this gtk2.c and report any errors
(be they compile errors or runtime errors or keyboard problems). Your help is
always greatly appreciated.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/*
* QEMU GTK2 display driver
* based on SDL driver by Fabrice
*
* Copyright (c) 2005 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include vl.h
#include gtk/gtk.h
#include gdk/gdk.h
#include fullscreen.h
/* define our own bitshift enums to allow qemugtk to know difference between
left and right alt - something gtk doesnt provide in its modifiers mask. this
uses qemu's own modifier_state[] map in order to guess correctly */
typedef enum
{
gtkshiftleft = 1 0,
gtkshiftright = 1 1,
gtkcontrolleft = 1 2,
gtkcontrolright = 1 3,
gtkaltleft = 1 4,
gtkaltright = 1 5,
gtkcapslock = 1 6
} gtk2keymod;
static GtkWidget *screen;
static GdkImage *image=NULL;
static GdkCursor *invisible_cursor;
static int ox = 0, oy = 0;
static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
static int last_vm_running;
static int gui_saved_grab;
static int gui_fullscreen;
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
static int gui_grab_code = gtkaltleft | gtkcontrolleft;
static uint8_t modifiers_state[256];
static unsigned int cw, ch;
static gint cx, cy;
static gboolean gtk2_expose(GtkWidget *wid, GdkEventExpose *event)
{
gdk_draw_image(wid-window, wid-style-fg_gc[GTK_WIDGET_STATE(wid)],
image, event-area.x, event-area.y, event-area.x, event-area.y,
event-area.width, event-area.height);
return TRUE;
}
static void gtk2_update(DisplayState *ds, int x, int y, int w, int h)
{
//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
GdkEventExpose ev;
ev.area.x = x;
ev.area.y = y;
ev.area.width = w;
ev.area.height = h;
gtk2_expose(screen, ev);
}
static void gtk2_resize(DisplayState *ds, int w, int h)
{
//printf( resizing to %d %d\n, w, h);
if (gui_fullscreen)
{
if (cw != w || ch != h)
fullscreen_switch(cx, cy, w, h); /* changing video modes */
//gtk_window_fullscreen(GTK_WINDOW(screen));
}
else
{
//gtk_window_unfullscreen(GTK_WINDOW(screen));
}
cw = w; ch = h;
if (image)
g_object_unref(image);
/* gdk_visual_get_best_with_depth() ??? but then how to paint onto window? */
image = gdk_image_new(GDK_IMAGE_NORMAL, gdk_visual_get_system(), w, h);
gdk_image_set_colormap(image, gdk_colormap_get_system());
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 07:58:14PM -0400, Jim C. Brown wrote: Well, no, that isn't it. The keymap files are based on X11 keycodes, so even if you could use this option it wouldn't work at all. More digging around in sdl.c revealed that SDL on Linux returns X11 keycodes as GTK on Linux does, while on Windows SDL returns the raw scan code. I know the offending function. This is the culprit: static uint8_t gtk2_keyevent_to_keycode(const GdkEventKey *ev) Apparently, that does not work for win32 gtk. In fact, that is apparently the Windows virtual key code, not the raw scancode. Hence the funny characters. The good news is that this is an easy fix. I've cleaned up the code a little bit, and attached a new gtk2.c to this email. What I really need is a Win32 programmer to proofread this, make sure I got it right. Since no Win32 person on this list or in the qemu irc channel offered to help me, I can not even guarrentee this will compile. And if it does compile, it is possible that keys will not work right due to lost of information due to casting (this is unlikely as all scancodes can be represented as a single byte, and it seems all Windows virtual key codes can be represented in at least two bytes). Still, I work with what I have to go on. Try this gtk2.c and report any errors (be they compile errors or runtime errors or keyboard problems). Your help is always greatly appreciated. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Wed, Jun 22, 2005 at 09:17:23AM -0400, Jim C. Brown wrote: Still, I work with what I have to go on. Try this gtk2.c and report any errors (be they compile errors or runtime errors or keyboard problems). Your help is always greatly appreciated. This version of gtk2.c includes the right header file (at least according to MSDN). However, after some deeper examination of the issue, it looks like it would be better to convert the virtual key codes to the us keyboard scancodes via some sort of keymap (similar to the X11 case). -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
I seem to be having problems sending attachments. Hopefully this email
will get through this time.
On Wed, Jun 22, 2005 at 09:17:23AM -0400, Jim C. Brown wrote:
Still, I work with what I have to go on. Try this gtk2.c and report any errors
(be they compile errors or runtime errors or keyboard problems). Your help is
always greatly appreciated.
This version of gtk2.c includes the right header file (at least according to
MSDN).
However, after some deeper examination of the issue, it looks like it would be
better to convert the virtual key codes to the us keyboard scancodes via some
sort of keymap (similar to the X11 case).
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/*
* QEMU GTK2 display driver
* based on SDL driver by Fabrice
*
* Copyright (c) 2005 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include vl.h
#include gtk/gtk.h
#include gdk/gdk.h
#include fullscreen.h
/* define our own bitshift enums to allow qemugtk to know difference between
left and right alt - something gtk doesnt provide in its modifiers mask. this
uses qemu's own modifier_state[] map in order to guess correctly */
typedef enum
{
gtkshiftleft = 1 0,
gtkshiftright = 1 1,
gtkcontrolleft = 1 2,
gtkcontrolright = 1 3,
gtkaltleft = 1 4,
gtkaltright = 1 5,
gtkcapslock = 1 6
} gtk2keymod;
static GtkWidget *screen;
static GdkImage *image=NULL;
static GdkCursor *invisible_cursor;
static int ox = 0, oy = 0;
static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
static int last_vm_running;
static int gui_saved_grab;
static int gui_fullscreen;
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
static int gui_grab_code = gtkaltleft | gtkcontrolleft;
static uint8_t modifiers_state[256];
static unsigned int cw, ch;
static gint cx, cy;
static gboolean gtk2_expose(GtkWidget *wid, GdkEventExpose *event)
{
gdk_draw_image(wid-window, wid-style-fg_gc[GTK_WIDGET_STATE(wid)],
image, event-area.x, event-area.y, event-area.x, event-area.y,
event-area.width, event-area.height);
return TRUE;
}
static void gtk2_update(DisplayState *ds, int x, int y, int w, int h)
{
//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
GdkEventExpose ev;
ev.area.x = x;
ev.area.y = y;
ev.area.width = w;
ev.area.height = h;
gtk2_expose(screen, ev);
}
static void gtk2_resize(DisplayState *ds, int w, int h)
{
//printf( resizing to %d %d\n, w, h);
if (gui_fullscreen)
{
if (cw != w || ch != h)
fullscreen_switch(cx, cy, w, h); /* changing video modes */
//gtk_window_fullscreen(GTK_WINDOW(screen));
}
else
{
//gtk_window_unfullscreen(GTK_WINDOW(screen));
}
cw = w; ch = h;
if (image)
g_object_unref(image);
/* gdk_visual_get_best_with_depth() ??? but then how to paint onto window? */
image = gdk_image_new(GDK_IMAGE_NORMAL, gdk_visual_get_system(), w, h);
gdk_image_set_colormap(image, gdk_colormap_get_system());
gtk_window_set_default_size(GTK_WINDOW(screen), w, h);
gtk_widget_set_size_request(screen, w, h);
gtk_window_resize(GTK_WINDOW(screen), w, h);
ds-data = image-mem;
ds-linesize = image-bpl;
ds-depth = image-bits_per_pixel;
ds-width = w;
ds-height = h;
gtk2_update(ds, 0, 0, w, h);
}
/* generic keyboard conversion */
#include gdk_keysym.h
#include keymaps.c
static kbd_layout_t *kbd_layout = NULL;
static uint8_t gtk2_keyevent_to_keycode_generic(const GdkEventKey *ev)
{
int keysym;
/* workaround for X11+SDL bug with AltGR - is it still needed for Gtk2? */
keysym = ev-keyval;
if (keysym == 0 ev-hardware_keycode == 113)
keysym = GDK_Mode_switch;
return keysym2scancode(kbd_layout, keysym);
}
/* specific keyboard conversions from scan codes */
#if
Re: [Qemu-devel] quick gtk2.c update
On Wed, Jun 22, 2005 at 02:53:03PM -0400, Jim C. Brown wrote:
This version of gtk2.c includes the right header file (at least according to
MSDN).
However, after some deeper examination of the issue, it looks like it would be
better to convert the virtual key codes to the us keyboard scancodes via some
sort of keymap (similar to the X11 case).
Ok this is probably the final revision. I had the code vindicated by an actual
Windows programmer. He says it should work fine. It should compile, run, and
make
qemu under gtk usable. Also I modified it so it lets u know when u are using
GTK.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.
/*
* QEMU GTK2 display driver
* based on SDL driver by Fabrice
*
* Copyright (c) 2005 Jim Brown
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include vl.h
#include gtk/gtk.h
#include gdk/gdk.h
#include fullscreen.h
/* define our own bitshift enums to allow qemugtk to know difference between
left and right alt - something gtk doesnt provide in its modifiers mask. this
uses qemu's own modifier_state[] map in order to guess correctly */
typedef enum
{
gtkshiftleft = 1 0,
gtkshiftright = 1 1,
gtkcontrolleft = 1 2,
gtkcontrolright = 1 3,
gtkaltleft = 1 4,
gtkaltright = 1 5,
gtkcapslock = 1 6
} gtk2keymod;
static GtkWidget *screen;
static GdkImage *image=NULL;
static GdkCursor *invisible_cursor;
static int ox = 0, oy = 0;
static int gui_grab; /* if true, all keyboard/mouse events are grabbed */
static int last_vm_running;
static int gui_saved_grab;
static int gui_fullscreen;
static int gui_key_modifier_pressed;
static int gui_keysym;
static int gui_fullscreen_initial_grab;
static int gui_grab_code = gtkaltleft | gtkcontrolleft;
static uint8_t modifiers_state[256];
static unsigned int cw, ch;
static gint cx, cy;
static gboolean gtk2_expose(GtkWidget *wid, GdkEventExpose *event)
{
gdk_draw_image(wid-window, wid-style-fg_gc[GTK_WIDGET_STATE(wid)],
image, event-area.x, event-area.y, event-area.x, event-area.y,
event-area.width, event-area.height);
return TRUE;
}
static void gtk2_update(DisplayState *ds, int x, int y, int w, int h)
{
//printf(updating x=%d y=%d w=%d h=%d\n, x, y, w, h);
GdkEventExpose ev;
ev.area.x = x;
ev.area.y = y;
ev.area.width = w;
ev.area.height = h;
gtk2_expose(screen, ev);
}
static void gtk2_resize(DisplayState *ds, int w, int h)
{
//printf( resizing to %d %d\n, w, h);
if (gui_fullscreen)
{
if (cw != w || ch != h)
fullscreen_switch(cx, cy, w, h); /* changing video modes */
//gtk_window_fullscreen(GTK_WINDOW(screen));
}
else
{
//gtk_window_unfullscreen(GTK_WINDOW(screen));
}
cw = w; ch = h;
if (image)
g_object_unref(image);
/* gdk_visual_get_best_with_depth() ??? but then how to paint onto window? */
image = gdk_image_new(GDK_IMAGE_NORMAL, gdk_visual_get_system(), w, h);
gdk_image_set_colormap(image, gdk_colormap_get_system());
gtk_window_set_default_size(GTK_WINDOW(screen), w, h);
gtk_widget_set_size_request(screen, w, h);
gtk_window_resize(GTK_WINDOW(screen), w, h);
ds-data = image-mem;
ds-linesize = image-bpl;
ds-depth = image-bits_per_pixel;
ds-width = w;
ds-height = h;
gtk2_update(ds, 0, 0, w, h);
}
/* generic keyboard conversion */
#include gdk_keysym.h
#include keymaps.c
static kbd_layout_t *kbd_layout = NULL;
static uint8_t gtk2_keyevent_to_keycode_generic(const GdkEventKey *ev)
{
int keysym;
/* workaround for X11+SDL bug with AltGR - is it still needed for Gtk2? */
keysym = ev-keyval;
if (keysym == 0 ev-hardware_keycode == 113)
keysym = GDK_Mode_switch;
return keysym2scancode(kbd_layout, keysym);
}
/* specific keyboard conversions from scan codes */
#if defined(_WIN32)
#include windows.h
static UINT
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown Ok this is probably the final revision. I had the code vindicated by an actual Windows programmer. He says it should work fine. It should compile, run, and make Okay... I compiled it and the keys do appear to work. That problem does appear to be fixed. It doesn't look like the 'insert' key toggles between insert / overstrike when I use the Win3 wordpad to read a file. However, this is in the regular qemu 0.70, so I don't know if it's a problem with qemu, or Win 3 wordpad. Now, while running my Win 3 test image, I notice that double clicking doesn't work. I couldn't get anything to open up no matter how fast I clicked. Single clicking works okay, though. qemu under gtk usable. Also I modified it so it lets u know when u are using GTK. I noticed that immediately when I ran it... Nice. Thanks. Still, I work with what I have to go on. Try this gtk2.c and report any errors (be they compile errors or runtime errors or keyboard problems). Your help is always greatly appreciated. I'm glad I'm able to help. The previous qemu errors I've reported have been completely ignored! At least you are taking an active interest in what a mere user has to say ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Monday, June 20, 2005, 3:59:11, Jim C. Brown wrote: I did find a GTK Windows tutorial at http://wolfpack.twu.net/docs/gtkwin32/, but that says to install the dlls to the System folder. Thanks to people like that I had to put detection of such broken installs to the GTK+ installer distributed on http://gimp-win.sf.net/ because we've had too many problems with Gimp not starting thanks to old GTK+ libraries in the PATH. -- Jernej Simoncic http://deepthought.ena.si/ If it does exist, it's out of date. -- Arnold's Second Law of Documentation ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 4:27:04, [EMAIL PROTECTED] wrote: I'd rather keep them in the qemu directory. Just like I do with sdl.dll Semi-official place to put GTK+ libraries on Windows is C:\Program Files\Common Files\GTK\2.0, and then adding bin\ subdirectory to PATH. This is what GTK+ installers do by default. BTW, for compiling GTK+ programs, I set the PATH specifically for MSys so that my system-installed GTK+ doesn't interfere with the dev environment (also, this allows me to compile for a certain GTK+ version without configure complaining - GTK+ programs that are written for GTK+ 2.4 and earlier won't be able to open filenames containing non-ascii characters on Windows when compiled with GTK+ 2.6). -- Jernej Simoncic http://deepthought.ena.si/ Hot glass looks the same as cold glass. -- Cirino's Law of Burnt Fingers ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 6:28:44, Jim C. Brown wrote: This is a particularly perplexing error, considering that a) this error should only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled app or 2) use a mingw/cygwin compiled GTK with a MSVC compiled app. Since you used mingw for both, I have not the slighest clue why this occurs. GTK+ and it's dependencies automatically specify -mms-bitfields when they're ocnfigured, so that you can use the same libraries for both MSVC and MinGW-compiled programs. -- Jernej Simoncic http://deepthought.ena.si/ Beauty times brains equals a constant. -- Beckhap's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 4:58:06, [EMAIL PROTECTED] wrote: No idea what it really means. Other than what it actually says. Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. -- Jernej Simoncic http://deepthought.ena.si/ The world is more complicated than most of our theories make it out to be. -- Berkeley's First Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 12:42:56PM +0200, Jernej Simon?i? wrote: On Tuesday, June 21, 2005, 4:58:06, [EMAIL PROTECTED] wrote: No idea what it really means. Other than what it actually says. Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. Aha. I wasn't aware of that ... so qemu was most likely built without -mms-bitfields. (I knew the option exists, but I didn't know it was the default.) I'll take a look at modifying the Makefile to support this. The world is more complicated than most of our theories make it out to be. -- Berkeley's First Law Indeed. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
This is a particularly perplexing error, considering that a) this error should only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled I downloaded the libraries and devel files from the link Jernej Simoncic recommended. It does seem to be a main win gtk distrib location. (As somebody pointed out, actually building gtk etc. under Mingw is a pita. I haven't tried, but judging from all the stuff that would be needed to build it, I suspect that's true.) The unzip into the proper mingw directory structure. Gtk Container period... other than GtkWindow.) There is also c) mixing GTK 2.2 and GTK 2.4 (or possibly GTK 2.4 and GTK 2.6) headers and libraries together (e.g. including the GTK 2.2 headers in qemu but using the GTK 2.4 libraries or something). I'm using the versions recommended and distributed on http://www.gimp.org/~tml/gimp/win32/ I get the same error regardless whether I'm using the recommended version or the bleeding edge version. It is possible that the 2 different mingw environments could have introduced incompatibilities (a very remote possibility). Perhaps recompiling GTK and its dependencies inside the new mingw environment would produce valid libraries. Or it might trash the new environment completely...*shrug* I don't know how to recompile all that stuff. I'm just downloading the pre-built devel libraries. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 18:27:10, [EMAIL PROTECTED] wrote: I downloaded the libraries and devel files from the link Jernej Simoncic recommended. It does seem to be a main win gtk distrib location. (As somebody pointed out, actually building gtk etc. under Mingw is a pita. I haven't tried, but judging from all the stuff that would be needed to build it, I suspect that's true.) The unzip into the proper mingw directory structure. Did you unzip to /mingw or to /? If the latter, you'll probably have problems, since MSys expects that the executables in /bin use the MSys runtime, and it won't pass the command-line parameters properly. I get the same error regardless whether I'm using the recommended version or the bleeding edge version. Just adjust your CFLAGS to contain -mms-bitfields before configuring Qemu. -- Jernej Simoncic http://deepthought.ena.si/ No matter what goes wrong, it will probably look right. -- Scott's First Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 18:30:07, [EMAIL PROTECTED] wrote: Do a export CFLAGS=$CFLAGS -mms-bitfields before configuring and compiling any GTK+ program on Windows - the libraries are always built to be compatible with MSVC so that you can use 1 set of libraries for all programs. I'll have to wait until Jim sends me the changes. I'm not a developer and I have no idea what you mean by export. Type export CFLAGS=$CFLAGS -mms-bitfields in MSys' bash before running ./configure (or simply add it to ~/.bashrc so you don't have to type it every time). Although the mingw/msys devel environment might work under Linux WINE, he wouldn't have any way to run test the resulting executables. MSys itself won't, since msys is actually stripped-down Cygwin. It is possible to cross-compile GTK+ programs from Linux (and it's definitely faster than under MSys, since bash+gcc are slow as hell on Win32; apparently, it's also almost easier to set up a cross-compilation environment in Linux than MSys on Windows for GTK+). -- Jernej Simoncic http://deepthought.ena.si/ The larger the project or job, the less time there is to do it. -- Old Engineer's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jernej Simonèiè [EMAIL PROTECTED] The unzip into the proper mingw directory structure. Did you unzip to /mingw or to /? If the latter, you'll probably have Into the mingw directory. That part seems to compile etc. It's the resulting program that is screwed up some how. export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tuesday, June 21, 2005, 21:40:26, [EMAIL PROTECTED] wrote: export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Hmm, it's been a while since I last tried compiling Qemu, but maybe you'll need to edit the makefiles to actually include that flag. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. -- Jernej Simoncic http://deepthought.ena.si/ Possessions increase to fill the space available for their storage. -- Ryan's Application of Parkinson's Law ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jernej Simonèiè Hmm, it's been a while since I last tried compiling Qemu, but maybe you'll need to edit the makefiles to actually include that flag. That's what I did. He sent me the patch to do that. It runs, but there are keyboard problems. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. Putting libraries like this in a common location is always a bad thing. That means the files whill have to be distributed with qemu And not everybody installs qemu over old versions, so you can't really expect the files to already be there from last time. It just seems fundamentally wrong to have a small emulator with very large libraries, just to satisfy some gui bloat. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. I do like the idea of a gui... Really. I'm just saying that I think 6meg is a bit large for a program that's only 780k by itself. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 02:40:26PM -0500, [EMAIL PROTECTED] wrote: export CFLAGS=$CFLAGS -mms-bitfields Okay, I tried that. I then did a 'make clean'. Then the config, then the regular make But running the resulting qemu is still giving the same error. Not the slightest clue why that should be. Unless make or gcc was ignoring the CFLAGS variable (or you used different shells). You can try the Makefile.target patch I sent, that may give better results. Considering how big the GTK libraries are for Windows, to be honest, I'm not so sure it's a good idea, anyway. The sdl library is only 300k and can be included with qemu. The gtk libraries are more than 6 meg and would be a little big to include with qemu. It just doesn't seem right to have the libraries being 8 times larger than the main program. On Linux, the SDL library is 2.5M and the GTK library is 16.5M So I understand the feeling. However, if we can keep the Windows and Linux versions unified with GTK, I think that the benefit would be sigficant. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 04:19:33PM -0500, [EMAIL PROTECTED] wrote: I'd say it's worth it, if Qemu gains a usable GUI this way. GTK+ libraries are ~3,5MB download, and only need to be installed once. Putting libraries like this in a common location is always a bad thing. That means the files whill have to be distributed with qemu I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. GTK libraries are not part of qemu, they are a separate resource that qemu depends on. And not everybody installs qemu over old versions, so you can't really expect the files to already be there from last time. It just seems fundamentally wrong to have a small emulator with very large libraries, just to satisfy some gui bloat. I do like the idea of a gui... Really. I'm just saying that I think 6meg is a bit large for a program that's only 780k by itself. qemu is 3.4M here. So I don't think that is so bad. Especially when that one set of 6M libs can be shared by many different applications (qemu, xchat, etc). It is possible to rewrite the GTK code so it is only written in GDK (the only GTK object we use is the GtkWindow, which I guess could be replaced by a GdkWindow). GDK looks a lot smaller than GTK over here (4M vs 16M). As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. A GUI is coming soon. I think. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. It's a very bad idea to have the installer need to go back on to the net to download something else. The user should get the whole thing at once. GTK libraries are not part of qemu, they are a separate resource that qemu depends on. As far as the user is concerned, they are part of qemu. qemu is 3.4M here. So I don't think that is so bad. Especially when that one It shouldn't be. There isn't that much conceptually different between windows and linux that should cause it to be that big. set of 6M libs can be shared by many different applications (qemu, xchat, etc). Not under windows, it wont be. For us Windows users, qemu will be the only program we use that will need gtk libs. Realistically, we don't need GTK. We've already got a GUI with an api. That's what windows programmers use. The vast majority of us will never use xchat etc. Qemu may be the only one they use. And it's not a good idea to distribute the libraries seperately. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. But it's not usable on Windows yet. As I said, so far, I'm not seeing *any* gui. Even the keyboard is messed up, so you can't even use the guest OS. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. I never use full screen, myself. I much prefer a window. Preferably one that's resizable, scroll bars, etc. etc. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. As I said in the other message (which I may have accidently sent directly to you, instead of the list) It's not doing the regular US keyboard. At least it doesn't eappear to be. I can get symbols, a few letters, but not the whole thing. And none of it is normal. Press '1' to get 'n' and so on. However, it doesn't appear that the -k keyboard option works for the windows version. I tried my builds and the official 0.70 build and they don't accept it either. I tried -k fr -k de -k en-us and so on, and they don't recognise it. (I've never tried the -k option before, but according to the docs, it isn't needed for Windows builds. So it may not be enabled.) So, assuming the problem is that gtk can't recognise I'm using a US keyboard, I can't do anything to force it. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Tue, Jun 21, 2005 at 05:45:12PM -0500, [EMAIL PROTECTED] wrote: GTK libraries are not part of qemu, they are a separate resource that qemu depends on. As far as the user is concerned, they are part of qemu. I must disagree here. If a user already has xchat 2 installed, and that person wants to try to use qemu with the GTK interface, they already have the libraries that they need. Including a set of GTK libraries just for qemu would not only be redundant in this case, it could potentially cause breakage to occur. I disagree. I think distributing the GTK library with qemu (even for windows versions) is a very bad idea. At most, the qemu installer should just download and run the GTK installer. At most. It's a very bad idea to have the installer need to go back on to the net to download something else. The user should get the whole thing at once. They should only get this library if they don't already have a copy installed. Of course there is a simple answer to this. Provide 3 qemu binaries for Windows: one that includes GTK support as well as the GTK libraries (so the installer can put them into the Common Files folder), one that includes GTK support but not the libraries, and one that has only SDL support. That's the dumb last resort option. Let's see who can come up with a smarter one. set of 6M libs can be shared by many different applications (qemu, xchat, etc). Not under windows, it wont be. For us Windows users, qemu will be the only program we use that will need gtk libs. Realistically, we don't need GTK. We've already got a GUI with an api. That's what windows programmers use. The vast majority of us will never use xchat etc. Qemu may be the only one they use. Ok, that is a valid point. I also agree that given what the GTK layer in qemu actually does, that is too much lot of overkill. (It would be really simple to just use pure GDK - the majority of the code is GDK.) However, I believe that the benefit of sharing the same GUI between Windows and Linux outweights this cost (esp. if what you say is true, that Windows builds are not very well maintained). And it's not a good idea to distribute the libraries seperately. Agreed. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a good solution for that. As for the gui... Well, I haven't seen that yet. What little I see looks the same boring Windows window that qemu always runs in. The gtk version isn't usable yet. The GTK version, on Linux, is perfectly usable. It is no more usable than the SDL version, but no less. But it's not usable on Windows yet. As I said, so far, I'm not seeing *any* gui. Even the keyboard is messed up, so you can't even use the guest OS. There is no GUI yet. I could easily make a crappy one in, say, 20 minutes. It'd work fine, but it may not be a lot of fun to use. For that matter, it may not be that useful. I'm waiting to hear from Fabrice and Sebastian for the GUI they have planned on top of the GTK layer. It seems that Fabrice is very picky when it comes to the GUI of choice for qemu. On Windows, you have no fullscreen support. Everything else should be exactly the same. If it's not, I'll try to fix it. I never use full screen, myself. I much prefer a window. Preferably one that's resizable, scroll bars, etc. etc. This isn't very difficult to do at all, and the code to do this for Linux and Windows should be identical. I'd like to fix the current bugs first though (on the off chance that there happens to be a difference on Windows that I don't know about). Once we fix those bugs, I'll look into making the qemu window resizable. It runs, but there are keyboard problems. What keyboard problems? There shouldn't be any for the GTK version. As I said in the other message (which I may have accidently sent directly to you, instead of the list) It's not doing the regular US keyboard. At least it doesn't eappear to be. It should. But it doesn't. Disturbing. I can get symbols, a few letters, but not the whole thing. And none of it is normal. Press '1' to get 'n' and so on. Yes, that is quite disgusting. However, it doesn't appear that the -k keyboard option works for the windows version. I tried my builds and the official 0.70 build and they don't accept it either. I tried -k fr -k de -k en-us and so on, and they don't recognise it. (I've never tried the -k option before, but according to the docs, it isn't needed for Windows builds. So it may not be enabled.) So, assuming the problem is that gtk can't recognise I'm using a US keyboard, I can't do anything to force it. Well, no, that isn't it. The keymap files are based on X11
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown I must disagree here. If a user already has xchat 2 installed, and that person wants to try to use qemu with the GTK interface, they already have the libraries that they need. Including a set of GTK libraries just for qemu would not only be redundant in this case, it could potentially cause breakage to occur. That's why you are supposed to put them in the directory of the app. It keeps from cluttering up the rest of the OS, possibly causing confusion, breakage, etc. with more than one version installed in various places (quite possible under windows) or having a damaged, broken one installed in the first place Windows looks. They should only get this library if they don't already have a copy installed. Which will be practically every qemu user. Of course there is a simple answer to this. Provide 3 qemu binaries for Windows: one that includes GTK support as well as the GTK libraries (so the installer can put them into the Common Files folder), one that includes GTK support but not Putting more stuff into the common files folders is just going to be 'clutter'. Things will never get used by any other application. Eventually the user will even entirely forget they are there. It just ends up being clutter. Or put them in the Windows system directory. Too much junk gets put there already due to years and years of poor programming, careless authors, indifferent programmers, and Microsoft's encouragement. I think the idea of using C:\Programing Files\Common Files\GTK 2.0 is a good solution for that. In theory. That's kind of what the directory is for. But that also assumes a few other things... Like those files actually might possibly ever get used by some other app. Not too likely for a Windows user. Second, by putting them in a common location, you open the possibility that they'll get replaced with newer versions. Which may not work right, if at all. That GTK website specifically mentions that certain versions are broken for Windows. By bundling the libraries with qemu, and keeping them in the qemu directory, you can guarantee that the user has versions that work right and are compatible with qemu. No -mms-whatever struct issue or anything else. However, none of that's really relevant, since at this point the gtk stuff doesn't even work under windows, so there's no point in distributing anything. There is no GUI yet. I could easily make a crappy one in, say, 20 minutes. It'd work fine, but it may not be a lot of fun to use. For that matter, it may not be that useful. Well, maybe not 'gui', but something that tells the user they are indeed running the GTK version and not the SDL version. It's not doing the regular US keyboard. At least it doesn't eappear to be. It should. But it doesn't. Disturbing. [shrug] All I can do is try to run it and report... I don't know qemu, gtk, or general mingw development to be able to say more. GetKeyboardLayout() or MakVirtualKeyEx(). What I really need is a Win32 programmer to proofread this, make sure I got it right. That would help They could help you debug this stuff. All I can do is try to compile it and run it. Not very helpful. Depending on how soon I can get to the patches you post, the test cycle may takes days for each event. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown Sorry I hadn't got back to you sooner, but I was busy Some good news... Keep reading. So I copied about 6 meg of library files to my qemu test directory. Strange. I'm not too familiar with the Windows equivulent of LD_LIBRARY_PATH. MingW's MSYS is a seperate, isolated linux style environment. My qemu directory is outside of that, in normal Windows XP area. So it wouldn't know about those libraries unless they all get copied to the same directory as qemu. I did find a GTK Windows tutorial at http://wolfpack.twu.net/docs/gtkwin32/, but that says to install the dlls to the System folder. I'm an old windows user Any thing that says it's okay to drop random libraries into the system folder is something that I don't trust! I'd rather keep them in the qemu directory. Just like I do with sdl.dll This time it stopped complaining, but after a couple seconds, a Windows box poped up saying an error occured and that it was shutting qemu down. I don't have any further information to give you. Sorry. Good news... Tonight I decided to test my Mingw/MSys environment. I built the regular SDL version that I've done several times before. It too failed. There's not much telling what is causing it to fail. Qemu seems rather sensitive to the slightest change in build environment. Anyway, the last time I built it succesfully, I make an archive copy of my whole msys directory. Which includes the compiler, and everything. So I went back to it. Rebuilt qemu just to make sure. It worked. I then copied the directory with your gtk version of qemu over to this new version of msys. After a few problems getting the gtk stuff reinstalled, I rebuilt your gtk version. This time, it's running! (At least I *assume* it's running. Everything looks identical to the sdl version, so I don't really have any way to know for sure. In other words, there's a regular Windows title bar with nothing else.) I haven't done any real testing of it yet, but I thought you'd at least want to know that it can be built under Mingw/MSys now. So far, all I've really done is booted Win 3.11 and Win95. Opened a few guest windows. Moved the qemu window around a bit, and shut them down. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Jim C. Brown There's not much telling what is causing it to fail. Qemu seems rather sensitive to the slightest change in build environment. Not the most reliable development environment. No, it's not... I think some of it is inherent in the GCC stuff. Others, just the general build environment. I've tried compiling some other gnu stuff under mingw, with varying success. (Meaning much of it didn't build, aborted, gave stack dumps, etc. etc.) This time, it's running! (At least I *assume* it's running. Everything Well, remember to pass the -use-gtk option to qemu. By default qemu will build with both sdl and gtk support, and if it has both, it will use the sdl support unless told to use gtk. Okay, I didn't know that. (Or I forgot about it.) That means I was running SDL. (That also means that even if it's ends up running in SDL mode, it still wants all those GTK libraries available. If it isn't using GTK, then it shouldn't need them.) Using that option now, I'm getting an error when I try to run qemu. *** Incompatable build! The code using GTK+ thinks GtkBox is of different size than it actually is in this build of GTK+. On Windows, this probably means that you have compiled your code with gcc without the -fnative-struct (or -mms-bitfileds) switch, or that you are using an unsupported compiler. *** No idea what it really means. Other than what it actually says. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Mon, Jun 20, 2005 at 09:27:04PM -0500, [EMAIL PROTECTED] wrote: Good news... Tonight I decided to test my Mingw/MSys environment. I built the regular SDL version that I've done several times before. It too failed. There's not much telling what is causing it to fail. Qemu seems rather sensitive to the slightest change in build environment. Not the most reliable development environment. This time, it's running! (At least I *assume* it's running. Everything looks identical to the sdl version, so I don't really have any way to know for sure. In other words, there's a regular Windows title bar with nothing else.) Well, remember to pass the -use-gtk option to qemu. By default qemu will build with both sdl and gtk support, and if it has both, it will use the sdl support unless told to use gtk. Quick way to verify if its using gtk or not - try to go into fullscreen mode. If it actually does go into fullscreen mode, its using SDL .. if the window just moves around, its using GTK. I haven't done any real testing of it yet, but I thought you'd at least want to know that it can be built under Mingw/MSys now. Yes, I am very pleased to hear this. So far, all I've really done is booted Win 3.11 and Win95. Opened a few guest windows. Moved the qemu window around a bit, and shut them down. Try resizing. The SDL window can be resized (at least under X11) but the GTK window can't. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Mon, Jun 20, 2005 at 09:58:06PM -0500, [EMAIL PROTECTED] wrote: Okay, I didn't know that. (Or I forgot about it.) That means I was running SDL. (That also means that even if it's ends up running in SDL mode, it still wants all those GTK libraries available. If it isn't using GTK, then it shouldn't need them.) Perhaps you are right (it is less of an issue in Linux since most workstations have GTK libraries installed anways ... if you have SDL then you probably have GTK as well). However, this approach would a) require introducing dlopen()/ LoadLibrary() into qemu in the right places (something I really hesitate to do) or b) require a link against glib for all cases (not just the GTK case) and use glib code to handle that (something I am even more relutant to do). Using that option now, I'm getting an error when I try to run qemu. *** Incompatable build! The code using GTK+ thinks GtkBox is of different size than it actually is in this build of GTK+. On Windows, this probably means that you have compiled your code with gcc without the -fnative-struct (or -mms-bitfileds) switch, or that you are using an unsupported compiler. *** No idea what it really means. Other than what it actually says. This is a particularly perplexing error, considering that a) this error should only show up if you 1) use a MSVC compiled GTK with a mingw/cygwin compiled app or 2) use a mingw/cygwin compiled GTK with a MSVC compiled app. Since you used mingw for both, I have not the slighest clue why this occurs. Especially since I do not use GtkBox anywhere in the gtk code. (I don't use any sort of Gtk Container period... other than GtkWindow.) There is also c) mixing GTK 2.2 and GTK 2.4 (or possibly GTK 2.4 and GTK 2.6) headers and libraries together (e.g. including the GTK 2.2 headers in qemu but using the GTK 2.4 libraries or something). Technically, it means that the sizes of the structure types don't match, which means that the library binary (GTK) and the application binary (qemu) are not compatible. It is possible that the 2 different mingw environments could have introduced incompatibilities (a very remote possibility). Perhaps recompiling GTK and its dependencies inside the new mingw environment would produce valid libraries. Or it might trash the new environment completely...*shrug* -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
Hello Jim, I have no time to test your patch :-( I think I can do it in august... Nevertheless, now gtk driver works (i suppose :-p), i have some old glade files on my hard disk to add Qemu-GTK GUI. Do you want I send it on the ML ? Maybe it can give you some idea if you have time to continue ? I tried to be as simple as firefox can be... Le dimanche 19 juin 2005 15:09 -0400, Jim C. Brown a crit : Minor changes to gtk2_send_mouse_move() for GTK 2.6 [...] -- Sebastien Bechet [EMAIL PROTECTED] seb.av7.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
From: Jim C. Brown Minor changes to gtk2_send_mouse_move() for GTK 2.6 Under Windows with MingW MSYS, I'm still getting the same compiler error that I reported to you before. Along with an assortment of warnings in the GDK stuff. Plus the usual qemu warnings. I'm still using the same setup as before, except right after I sent you the report back then, I upgraded to the bleeding edge gtk stuff and tried it again. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Mon, Jun 20, 2005 at 12:25:54AM +0200, Sebastien Bechet wrote: Hello Jim, I have no time to test your patch :-( I think I can do it in august... I have to know how you got GdkPixbuf to work with your GTK patch. I looked at using GdkPixbuf but it seems not flexible enough to support the graphic requirements of most OSes... I wish to understand how you got your version to show graphics images correctly. I did not think it was possible unless GdkImage was used directly. Nevertheless, now gtk driver works (i suppose :-p), Depends on how you define works. It is usable. Still a few oddities that need tending to. i have some old glade files on my hard disk to add Qemu-GTK GUI. Do you want I send it on the ML ? Maybe it can give you some idea if you have time to continue ? I tried to be as simple as firefox can be... I am not very good with GUI designing.. but I would not mind taking a look. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] quick gtk2.c update
On Sun, Jun 19, 2005 at 08:13:55PM -0500, [EMAIL PROTECTED] wrote: If that one doesn't work, try this one. (The only different is that I include gdk/win32/gdkwin32.h instead of gdk/gdkwin32.h) I also attach a gdkprivate-win32.h in case yours is missing (google seems to I'm not getting any errors about that. But maybe the build isn't getting that far. I'll go ahead and drop it into the qemu directory just in case. If you are not getting any errors about it, then you don't need it. Dropping it into the qemu directory probably wouldn't help at all. Shouldn't mess anything up, though. Okay... In gdk_set_window_pointer.c, you include #include gdk/win32/gdkwin32.h For my mingw / msys enviornment, that should be #include gdk/gdkwin32.h Fixing that, I do get a sucessful build. Ok. I've seen it done both ways so I wasn't sure which was correct for current GTK-win32. However, it doesn't run. Qemu, as usual, doesn't print out anything that could possibly be of any use to somebody having trouble. So, I dropped down to the command line and ran it again. This time I got a number of Windows errors saying it couldn't find the proper gtk etc. libraries. So I copied about 6 meg of library files to my qemu test directory. Strange. I'm not too familiar with the Windows equivulent of LD_LIBRARY_PATH. I did find a GTK Windows tutorial at http://wolfpack.twu.net/docs/gtkwin32/, but that says to install the dlls to the System folder. This time it stopped complaining, but after a couple seconds, a Windows box poped up saying an error occured and that it was shutting qemu down. I don't have any further information to give you. Sorry. I could make a modified gtk2.c which would printf() more debugging information. One that would print out enough information to tell me exactly which part of the code was causing the error and what the error was. If you are willing to help me do the debugging, I'll email you the modified code as well as detailed instructions and wait back for the results. This will have a slightly higher time commitment though. Thanks for helping me get this far. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
