Re: Window system dependant parts of gtk (sources), Win32 integration

[Owen Taylor <otaylor redhat com>]

Tor Lillqvist <tml@iki.fi> writes:

> I have been told earlier that it's best to keep a separate gdk source
> directory for each supported windowing system (X11, Win32, who knows
> what later). The core developers don't want to look at #ifdefs (and I
> agree). My current gdk sources are (being changed to be) like that, no
> X11 code in the gdk source files.
> 
> Now, as for the gtk directory, it already *mostly* don't need any
> window system specific conditional compilation at all. Except for
> these (in my current sources):
> 	- gtkfilesel has some chunks of #ifdef code
> 	- gtkfontsel also
> 	- gtkeditable, gtkselection, gtkentry: currently no ifdefs
> 	- gdkdnd: just one ifdef so it compiles, but it doesn't do anything
> 
> I now try to emulate the X11 selection stuff for CLIPBOARD in gdk (so
> the gtk code wouldn't need to have ifdefs), sending pseudo selection
> request and notify messages, to make the flow of control mimic the one
> on X11. It doesn't work very well, and really is an awful hack.

I agree that isn't a reasonable approach. gtkselection.c,
although it is completely layered on top of GDK, is basically
just an implementation of the ICCCM selection protocol.
 
A stub gtkselection.c that only implements XA_CLIPBOARD
(like Tk does for Win32) doesn't seem too bad to me.

> As the Win32 clipboard API is much simpler than the ICCM selection
> protocol (basically you can just call a function to store stuff on the
> clipboard, and another to get stuff from there), it really would be
> much simpler to call some gdk_clipboard_set and gdk_clipboard_get
> functions. Probably I will do that, put all the ICCM specific stuff in
> ifdefs.
> 
> Drag-and-drop too will be quite different I assume, haven't looked at
> it yet.

You can make the basic assumption that a most of gtkdnd.c isn't
applicable to Windows - the GDK layer abstracts out the differences
between Motif and Xdnd drag and drop protocols, but is stil quite tied
to X. (Though, probably more of gtkdnd.c is applicable than
gtkselection.c - there is some code for finding a target widget 
within a toplevel, for instance.)

The API, however, was designed with some glances at the Win32 system,
and doesn't even require that the DND implementation be
message-passing.
 
> Anyway, the main point of this message is: How strong is the aversion
> to having ifdefs in the gtk files?  Should the windowing system
> dependant parts of gtk sources be split off into a separate directory?
> Or should I keep parallell copies of the handful of affected gtk
> files, to be copied into the main gtk directory by Win32 developers
> who want to compile?

I guess my perspective is that Unix (X) is most important by a large
margin. Changes so that seriously decrease the readability or
maintainability of the Unix sources would be bad. (For an example of
what I mean by seriously decrease, I think that glib has too many
NATIVE_WIN32 ifdef's currently to be easily readable.)

That being said, a few #ifdef's, can in a few places, can
sometimes be the cleanest solution, and certainly are preferrable
over to large-scale code duplication. I don't think GTK+
has enough Unix-specificity to deserve being split into
window-system dependent and independent directories. (GDK 
_is_ the window-system dependent directory, to some extent)

A few techniques that can be used instead of large-scale
#ifdef's.

 1) Conditionally include files including window-specific 
    implementations. (I.e., Raph's suggestion)

 2) Have win32 and unix variants of a few key files, and
    use a different set of files for the Win32 build.

 3) Figure out a way of abstracting a window-system 
    dependency to the GDK level. (This is probably the
    most productive, if most difficult, strategy)
 
> When would be a good time to start thinking about integrating the
> Win32 stuff in the main gtk+ sources? Basically it would mean a new
> gdk-win32 directory and some portability changes (use G_DIR_SEPARATOR
> where appropriate, check HAVE_UNISTD_H, use GLib functions instead of
> doing things "by hand", etc) to gtk files Just a handful of gtk files
> would need some conditional code as outlined above.

I don't think we can get it in for 1.2. (In fact, the rough freeze
date for major changes for that is Dec 1, so only a few days away)

If it doesn't involve any significant changes visible from Unix
applications, it might be possible to make an interim release in a
couple of months that includes Win32 support.  (That is, not make that
wait for the next full development cycle)
 
> I haven't really looked at the newest additions gtklayout, gtkplug and
> gtksocket yet, just quickly #ifdeffed out the X11 parts to get them to
> compile.

gtklayout probably can be emulated in Win32 pretty easily, but
not much of the code is probably applicable. (It's entire
purpose is basically getting around X's 32768 pixel limitation
on window sizes)

gtkplug and gtksocket also are pretty X specific, though I
think Tk manages to achieve the functionality (inter-process
window embedding) on Win32 in some fashion.

> (I haven't had the time to look at Owen's glib main loop stuff yet
> either, sorry)

If you have a chance to take a look soon, that would be appreciated.
This will be in Glib 1.2, and we probably want to avoid changing
that API afterwards, if that can be avoided.

Regards,
                                        Owen