Problems under Wine with Win32 GTK libs
pl...@sbcglobal.net
fact that I can (with relatively few changes) cross-compile them with
MinGW and Tor's Win32 GTK dev-libs. So I never have to leave Linux (in
my case, Debian and Ubuntu) to produce workable, solid Win32
executables. Very cool.
But there is one problem: while the Windows versions operating in
Windows look almost identical to the Linux versions operating in Linux,
the same Windows versions have major problems in Wine. There are minor
things -- like needing some obscure Windows DLL (USP10.DLL), and
endless font complaints from Pango, and path problems not solved by the
GTK installers... But hey, I wouldn't be writing here if that were all
-- I don't care if the apps look great or even good in Wine, I just
want to see their behavior enough to know that they work, then make
them available to users -- without ever actually having to boot
Windows.
What ultimately keeps me from doing that is that in Wine, the apps are
visually "black on black" -- the backgrounds are black, and all of the
features except buttons are black too. That's worthless for debugging.
I tried installing a Windows Classic theme, hoping maybe that would
make the features distinct -- but all that did was make progress bars
also visible while upping the processor and memory load unacceptably
(by 5-times, roughly).
I realize that my problem is as much of a Win32 GTK issue (and maybe
even a Glade-build issue, for all I know) as it would be a Wine issue.
But since the apps seem to work flawlessly in "real windows", I'd just
like to find a Wine fix for the time being. Any workaround ideas?
Thanks.
Martin Liddle
pl...@sbcglobal.net writes
>
>I realize that my problem is as much of a Win32 GTK issue (and maybe
>even a Glade-build issue, for all I know) as it would be a Wine issue.
>But since the apps seem to work flawlessly in "real windows", I'd just
>like to find a Wine fix for the time being. Any workaround ideas?
>
have tried.
--
PLEASE NOTE NEW ADDRESS:
Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way,
Staveley, Chesterfield, Derbyshire, S43 3TW.
Web site: <http://www.tynecomp.co.uk>.
Rein Klazes
>
>I realize that my problem is as much of a Win32 GTK issue (and maybe
>even a Glade-build issue, for all I know) as it would be a Wine issue.
>But since the apps seem to work flawlessly in "real windows", I'd just
>like to find a Wine fix for the time being. Any workaround ideas?
>Thanks.
If you can create a small example program that shows the problem, create
a bug report at http://bugs.winehq.org and attach the test program.
Rein.
pl...@sbcglobal.net
> The first piece of information to provide is the version(s) of WINE you
> have tried.
Thanks. I've seen it with both versions I've used -- Debian Unstable
Package: wine (0.9-1), and now the latest available in the WinHQ apt
binary repository: 0.9.1-winehq-3.
The only other reference to this "black-on-black" behavior I can see on
the net is, interestingly, someone else who is doing the same thing as
me (cross-compiling GTK/Linux apps for Windows):
http://mail.gnome.org/archives/gtk-list/2005-June/msg00162.html
The only tip offered in that thread involved tailoring my Win32 GTK
code; which I could probably figure out, but it sort of defeats the
beauty of having the GUI code be truly "generic" in regard to platform.
pl...@sbcglobal.net
> If you can create a small example program that shows the problem, create
> a bug report at http://bugs.winehq.org and attach the test program.
Thanks, i will indeed look in to that.
In the mean time, your suggestion made me think about the simplest
robust GTK code that would exhibit the behavior -- so I literally
grabbed the GTK "Hello World!" tutorial code here:
http://www.gtk.org/tutorial/c58.html#SEC-HELLOWORLD
I compiled it as directed to a Linux executable following their
instructions -- no errors, no complaints, and the result works fine in
Linux. Then I cross-compiled the exact same code with these rather
explicit compile/link lines (in order to link to my batch of Win32 GTK
libs, which for this experiment I put in a folder named "lib_gtkwin32"
right next to helloworld.c):
To cross-compile helloworld.c:
i586-mingw32msvc-gcc -mms-bitfields -Ilib_gtkwin32/include/gtk-2.0 \
-Ilib_gtkwin32/lib/gtk-2.0/include -Ilib_gtkwin32/include/atk-1.0 \
-Ilib_gtkwin32/include/cairo -Ilib_gtkwin32/include/pango-1.0 \
-Ilib_gtkwin32/include/glib-2.0 -Ilib_gtkwin32/lib/glib-2.0/include \
-g -O2 -c -o helloworld.o helloworld.c
To cross-link helloworld.o to make helloworld.exe:
i586-mingw32msvc-gcc -mms-bitfields -g -O2 -o helloworld.exe
helloworld.o \
-Llib_gtkwin32/lib -latk-1.0.dll -lgmodule-2.0.dll -lpango-1.0.dll
-lcairo.dll \
-lgobject-2.0.dll -lpangocairo-1.0.dll -lgdk_pixbuf-2.0.dll
-lgthread-2.0.dll \
-lpangoft2-1.0.dll -lgdk-win32-2.0.dll -lgtk-win32-2.0.dll
-lpangowin32-1.0.dll \
-lgettextpo -liconv -lglib-2.0.dll -lintl
Again, no errors, no complaints. I even booted up my old Windows
standby to be sure the executable worked -- and it looks just like the
linux version.
But wine launches that same executable in "black-on-black" --
everything except the window border is non-viewable. However, the app
clearly "thinks" it is working right, since I can push the invisible
button and it terminates normally and as expected.
Incidentally, a bit more on what I see on Windows (specifically Win98):
There are two odd things. One, my cross-compiled GTK apps look great
overall, but they always launch from a DOS-like command shell that
hangs around until program termination. I just haven't had time to look
in to why this is, and it isn't causing problems with the apps. But it
suggests to me that maybe Windows sees something strange about my
executable. The other thing I see (in both Windows and Wine) is the
font warning:
(helloworld.exe:8): Pango-WARNING **: Couldn't load font "MS Shell Dlg
8" falling back to "Sans 8"
In fact, on Win98 (unlike a friend's WinXP box I got to test it on),
there is a good 30-second pause before that error appears then the
actual app GUI pops up -- suggesting to me that the app is looking for
this font. I mention in case this offers any clues too; eventually I'll
definitely need to track that font requirement down in GTK, because it
appears over and over endlessly on some of the more complex Glade
examples I've made.
pl...@sbcglobal.net
In trying to solve this, I also tested Gimp in Wine, to see if one of
the world's most popular GTK Win32 apps exhibited the same problem as
my apps in Wine. It did.
Some more googling turned up the fact that Gaim (probably the world's
most popular GTK Win32 app) uses a different GTK Win32 runtime
installer. And yes, I tried it... and sure enough now Wine runs Gimp
and all of my own apps perfectly :-)
So the urgency of this as a "wine bug", per-se, has dropped immensely
-- that is wine is still acting different from Windows, but only in
regard to what appears to be a "wine unfriendly" version of the GTK
installers (so I suppose I should now contact the GIMP devlopers with
my experience).
The wine-friendly Win32 GTK runtime installers are found here:
http://prdownloads.sourceforge.net/gaim/gtk-runtime-2.6.9-rev-a.exe?download
The wine-unfriendly Win32 GTK runtime installers came from here:
http://prdownloads.sourceforge.net/gimp-win/gtk%2B-2.6.9-setup.zip?download
And now I can debug my GTK Win32 ports without having to own a Windows
box :-)