Re: Gtk port to Win32 "progress report"

[Tor Lillqvist <tml hemuli tte vtt fi>]

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

OK, good, it's nice to know that my effort isn't duplicated.

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

Those are my thoughts, too. 

> I've been holding off a bit on applying the patch, 

Yes, reject my glib patch, based on this discussion I will submit an
improved one soon...

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

Yes, that is a problem with the nonspecific EXTERN approach, so I
think it's better to use a library-specific identifier.

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

Hmm, it seems you're correct. I thought I had checked for this, but
apparently I checked for the other combination: if the definition has
the __declspec(dllexport) but the declaration hasn't, MSVC complains.
The other way is OK... This is good news, keeping the .c files with
all those *API macros in them up-to-date with the CVS snapshots would
have been more difficult than just keeping the headers up-to-date. I
could even write an awk script/emacs function/whatever that inserts
the FOOAPI words in header files.

> Also, I don't really like the WIN32_BUT_NOT_CYGWIN define
> you use in a couple of places. [...] I'd rather see it as
> something more generic, like, say, NATIVE_WIN32.

Yes, you're right. I'll change to that.

> It strikes me that there probably will be essentially no code shared
> between the Win32-based and normal GDK, other than the public
> headers. 

Hmm, I decided not to do that, but if you and others think this would
be better, I guess I'll go along...

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

So, one can not/should not depend on changing the pixels originally
given to gdk_image_new_bitmap to change the GdkImage?

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

That's OK with me, as GDK is where most of the changes go, and GDK is
easy to keep synced. (Thank god that GTKAPI stuff isn't necessary in
the gtk*.c files after all.)

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

Yes, I will keep the list informed.

--tml