Re: Restructuring GDK for 1.3

[Owen Taylor <otaylor redhat com>]

"Shawn T . Amundson" <amundson@eventloop.com> writes:

> On Sun, Aug 08, 1999 at 10:51:12PM -0400, Owen Taylor wrote:
> > 
> > The GTK+-1.3 branch has been, so far, languishing.
> > I'd like to work on getting it up to speed. The
> > biggest bottleneck right now is getting the 
> > directory structure set up properly for 
> > multi-platform use.
> > 
> > I spent some time today trying some ideas in a local
> > copy of my tree, and came up with something that I was fairly
> > happy with.
> 
> My local tree has lots of beos port stuff hacked onto it, and 
> actually it's going quite well.  A lot of testgtk works, with
> a lot of problems.

Cool.

> > The main idea here is that we should have parallism
> > between the ports so the X specific stuff should
> > be moved into gdk/x11. The model is that 
> > 
> >  gdk/gdkwindow.c
> > 
> > includes win32/gdkwindow.i or x11/gdkwindow.i as appropriate. 
> > (The .i suffix I think is clearer than using .c or .h).
> > 
> > This is a little odd in the context of GDK, because
> > 95% of the content is going to end up in the .i files,
> > but I think this structure encourages sharing code
> > where possible and preventing code drift.
> 
> The primary problem with this is all the beos backend is 
> necessarily done making use of C++ code.  Autoconf doesn't 
> like compiling C code with a .c extention, making this method 
> a bit more a pain.  We can force usage of g++ for .c files, 
> but I don't really want to compile all the files (like gdkrgb) 
> with g++ if we can prevent it.  And we definately want libgtk 
> compiled with gcc.

Thanks for pointing out this issue ... I hadn't really 
thought of it and i.

There is nothing stopping one from having
a beos/gdkwindow.cc file in my scheme. I'd sort of like
to keep the practice of having a gdk/gdkwindow.c file
there, though it is a bit silly if they end up being
empty.
 
> Our tree is currently hacked so it only works on BeOS, so
> I haven't put a lot of work into autoconf.  I'd actually like
> to work hard on this and get some good method into the 1.3
> tree this week so I can do a release to show the BeOS port 
> thus far.

We need to figure out how the build proces will work on
non-autoconf platforms. That's native Win32, and also
probably OpenVMS. 

I don't know if BeOS is one of those platforms, or if
you can get automake/autoconf/libtool working properly.

[...]

> When is too soon to merge our stuff into 1.3?  It won't be perfect
> by a long shot for a long time, but it will be easier to do the 
> releases along with the rest and obviously X-based systems will not
> be affected except perhaps autoconf screwiness.  If we merge in some 
> stuff soon, we have a high degree of figuring the autoconf stuff out 
> faster I think.

I think as soon as we get the win32 stuff and x11 in some
semblence of their final order it should be OK to add
in the BeOS stuff. It sounds like will mostly be pretty
well isolated into its own directory.

Regards,
                                        Owen