Re: Gtk port to Win32 "progress report"

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml@hemuli.tte.vtt.fi> writes:

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

It hasn't been done before, though it has been endlessly debated.
It's nice to actually see somebody writing code on it. 

As a quick preface, I will say though that a toolkit on windows that
doesn't use native widgets doesn't have much hope of widespread
acceptance:

 * If you don't try to emulate the L&F of windows, the application
   is going to "look odd". (Windows users, unlike X users,
   aren't used to having 5 different looks onscreen at once)

 * If you do try to emulate the L&F, the final effect is going
   to be worse, because no matter how hard one tries, with
   a side-by-side comparison, it is going to look like a 
    shoddy imitation of windows.

That being said, I think a GDK port would have some use in
the end anyways - sufficiently cool software (like the GIMP)
probably can overcome the "it doesn't look like Windows" hurdle.

Also, work on such a port will almost certainly help if there
are future ports to things like Y or GGI/Berlin.
 
> (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.

I've been holding off a bit on applying the patch, because I
wanted to look some at comparable libraries to see how they
handled the __dllspec() stuff. I took a quick look this morning
at Tk, and there were two main differences:

 1) It uses EXTERN instead of FOOAPI as the #define. I like the
    look of that a bit better, but the FOOAPI usage has less
    namespace pollution, and it will make things easier 
    if one is including glib header files when compiling
    GDK, say. 

 2) It only puts the EXTERN declarations into the headers,
    and not into the sources themselves. If this works,
    I'd much rather keep the declarations out of the
    sources.

Also, I don't really like the WIN32_BUT_NOT_CYGWIN define
you use in a couple of places. Isn't there a "minwin" or
something that falls somewhere inbetween cygwin and the
normal compilers? If the platform specific define can't
be eliminated in favor of features-specific defines,
(and that looks a bit hard, here) I'd rather see it as
something more generic, like, say, NATIVE_WIN32.

Except for the GLIBAPI declarations in the .c files, the
patch looks fine for incorporation to me. What do other
people think? (Especially people who have programmed
on windows in the last 6 years.)

> 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 suspect that eventually, getting things like DND and selections
working will require some work at the libgtk level, since 
quite a few of the details of the protocol extend into the GTK
level. (gtkselection.c is pretty much all completely tied
to X)
 
> 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.

It strikes me that there probably will be essentially no code shared
between the Win32-based and normal GDK, other than the public
headers. So rather than #ifdef'ing the contents of every function, it
would be cleaner to split the Win32 GDK stuff into a separate
directory/. So you'd have something like:

 gtk/
 gdk/
 gdk-win32/

If there is significant code that could be reused, then it probably
should be split off, and you would have:

 gtk/
 gdk/
 gdk-unix/
 gdk-win32/

> 
> 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?

A GDK bitmap is precisely the same as a pixmap of depth 1, and as,
with pixmaps, you can only access the bits through X requests.

> Would using DirectDraw (of which I know next to nothing, but have
> hastily browsed through some code examples) be a good idea?
 
I certainly know less about it. But I might guess that it would be a
bad idea to use it in an initial implementation, though it could be
added as a later optimization. (I.e., get the stuff working correctly
using the standard parts of the Win32 API first). It might be
eventually be needed to get something like pixmap-based-theming to
perform half decently.

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

The Tk sources are certainly very much work looking at. (You might
want to also take a peek at the 8.1 sources, since, as I understand
it, the cross-platform support was essentially redone for 8.1)
 
> 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.

Hmmm, I really don't want to be messing up the GTK+ sources with
#ifdef WIN32 or even the DLL declarations until there is at least a
proof-of-concept implementation, and some idea of the "right way" to
do it. 

If you want to work on your stuff in a branch on the repository,
that could be arranged. Let me know.
 
> 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...

Let us know how things go. It would, at the minimum, be very
amusing to see testgtk running on a windows box. ;-)

Regards,
                                        Owen