Re: Gtk port to Win32 "progress report"
- From: Tor Lillqvist <tml hemuli tte vtt fi>
- To: gtk-devel-list redhat com
- Cc: otaylor redhat com
- Subject: Re: Gtk port to Win32 "progress report"
- Date: Tue, 18 Aug 1998 21:41:55 +0300 (EETDST)
> 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
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
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.
] [Thread Prev