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

[Raph Levien <raph acm org>]

Tor Lillqvist wrote:
> 
> 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.

I agree, and am very excited to see this happening.

[...]

> 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 think keeping gtk (as opposed to gdk) unified is a very good idea.
#ifdefs in the gtk sources don't bother me, although others might have a
different idea.

I don't think copying files around in the tree is a good idea. One thing
to look at is keeping the "meat" in .h files that are conditionally
#included. This is what Owen does for the xinput stuff in gdk.

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

These are probably nontrivial to port.

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

Owen's mainloop is designed to abstract over both the Win32 and Unix
models. It should aid with portability, at least in theory.

Raph