Gtk port to Win32 "progress report"



(Sorry if this is a duplicate, but I think my first message didn't get
throught as I used my non-work-related email address.)

I have been working for some weeks in my ample (apparently, although
my SO and son might disagree) free time on a port of gtk to Win32. In
this message I'll discuss some implementation issues. Comments,
please!

Especially comments like "don't bother, it's almost done already"
would be very welcome. I don't mind, this has still been a interesting
introduction into the inners of gdk and to Win32.

(Let me first say that I prefer Unix to Windoze as much as any person
on this list. I do this just because it is an interesting thing to do,
in a bizarrely perverted way. Beats watching TV ;-) I also have some
personal interest, in that it would be nice to have the GIMP working
on Win95 so I could use it with my scanner, which doesn't work on
Linux...)

I decided to make glib, gmodule, gdk and gtk into DLLs. This doesn't
introduce much difficulty per se, only the somewhat annoying fact that
you have to prefix each exported function and variable declaration (in
the headers) and function definition with the magic incantation
__declspec(dllexport) (when compiling the library in question) or
__declspec(dllimport) (when compiling client code that will use the
library).

I do this in what I guess is the normal way by defining macros
GLIBAPI, GDKAPI and GTKAPI in the header files which expand as
necessary (as "extern" on non-Win32). Of course this makes the headers
and sources a bit uglier, but not much. I hope this doesn't disturb
sensitive Unix programmers... and that (if my work is eventually
accepted into the official sources) people who add APIs to gdk and gtk
won't mind writing those GDKAPI and GTKAPI words before each exported
declaration and definition.

I normally compile using Watcom 10.6, but also try to make sure
everything compiles and works as well with MSVC 5.0 and Cygnus
GNU-Win32 B19.1. (With the current GNU-Win32 building a dll seems to
be quite complicated, though, and I don't even try.)

Glib was trivial, testglib works (except that with MSVC 5.0, the
%1000.1000f format in testglib crashes and burns...). I uploaded the
patch to glib some weeks ago, but so far it hasn't been accepted,
sigh. The new gmodule was also straightforward to implement for Win32.

Gdk is where the core difficulty is. This is where most of the #ifdefs
and Win32 specific code go. (Luckily this is also a part that gets
changed in the official sources quite infrequently, so it has been
easy to keep my working sources up-to-date.) I have concentrated on
the code needed to get something actually to show up on the screen, so
I have skipped all of dnd, selections and extended input devices
(tablet support etc), and haven't yet much of a clue what and how to
do about them. I am also quite sure that the way I play around with
Win32 DCs, palettes, brushes and whatnot isn't correct in all places,
but hey, isn't debugging supposed to be fun?

I decided to use typedefs for those Xlib types that have correspoiding
concepts in Win32. I.e. I use typedef HWND Window, typedef HBITMAP
Pixmap, etc.

How much used are gdk bitmaps? With X11, they are implemented as
XImages, ie on the client-side, with direct access to the bits. This
is somewhat difficult if I implement them with Win32 bitmaps (at least
the case where you provide initial contents for the bitmap, but still
want tobe able to get at the pixels directly). Gdk pixmaps correspond
better to Win32 bitmaps, in that you access them only through the API,
yes?

Would using DirectDraw (of which I know next to nothing, but have
hastily browsed through some code examples) be a good idea?

The X11/gdk event vs. Win32 message handling stuff is a bit in the air
still, but I got some good ideas from the X11 emulation layer in
Tk8.0.

I think gtk proper doesn't need many changes, as it depends on gdk for
all window system specific services. But, hundreds of those GTKAPIs
need to sprinkled through the .h and .c files... It would be nice to
get write access to the gtk CVS so that these changes could be put
into the official sources now. This shouldn't affect Unix compiles a
bit.

At this point I get gdk to compile and link (but do understand that
there are lots of black holes in the Win32 parts of the code that just
say /* ??? */, or do something silly that surely will crash). Also gtk
compiles and links. I haven't been able to link testgtk yet to see if
it manages to put a single pixel on the screen without crashing...,
because I haven't added all that GTKAPI stuff yet. After testgtk opens
its first window, only 90 % of the work is left, I guess...

--tml



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