The Jumpstart Unix Mozilla Project

Some history about NGLayout and Unix: Before October 26th, 1998, the NGLayout team was a small set of developers working almost entirely on a Win32 product. There was some support for Unix, but the reliability of the builds varied greatly from day to day. The Unix Front End (XFE) developers at Netscape were more focused on their current projects (Communicator 4.5 and the former Mozilla project) so Unix support was completely dependent on a few kind members of the NGLayout team who would keep the build alive whenever they got a chance. At the time, Motif was the expected toolkit that we would use to develop the Unix NGLayout component.

The world has changed. We are now building an entire product around the NGLayout project. XFE developers are now all focused on getting raptor up and running. We have decided that GTK is a more appropriate toolkit for the job we are trying to accomplish, and the role of the Front End has changed greatly.

Enter JUMP: The Jumpstart Unix Mozilla Project. Here is a list of items that need to be accomplished, understood or documented to make NGLayout accessible to all Unix developers. This is not a list of new features to add or improvements to make, it is what needs to be done to bring NGLayout/Mozilla on par with other free source development efforts.

Build system - The Unix build system on NGLayout is overly complicated and cumbersome. We would like to switch to autoconf.
XPFE - We need to get the XPFE using GTK on Unix - it currently uses Motif.

GTK Widgets
GTK gfx system
Startup
Event Loop
Fix remote display

Netlib - this has been changed for NGLayout to support multithreaded applications.

Check on Async. DNS - We don't even know the status of Asynchronous DNS in the new NetLib. Does it work? If it does work, is there a better way of doing this?
Other hacks that we needed pre-NGLayout - FE_SetReadPoll() hacks, etc. Do we still need them?

Other issues

Motif/AWT/Threading issues - Motif is not thread safe and any OJI Java VM probably uses Motif. Is this issue something for JVM vendors to worry about, or do we need to include some kind of support? Similar problems have been tackled in the past.
GTK Threading issues - GTK is not thread safe. XPFE currently runs on only one thread, but there is talk of making separate threads for each window. Should someone make GTK thread-safe or should we design our code so that we do not rely on this behavior?

Looking forward

Move to feature specific #ifdefs rather than OS/Version specific #ifdefs. There are many places where we use conventions like #ifdef SOLARIS when what we really want is #ifdef HAVE_UNSIGNED_BITYPES or something. Autoconf gives us these feature specific macros for free. Let's use them.
Purify - we need to start purifying early. The old codebase had plenty of very small leaks that were almost always ignored by developers because there were after bigger problems. Purify targets should be added to Makefiles.
gprof - we should also start profiling our code as early as possible. It will be easier to fix bottlenecks in the future if the codebase is already somewhat streamlined. Profile targets should be added to Makefiles. We may also need djw's gprof hack.
Warnings - we should start cleaning up warnings now so that developers don't simply give up on fixing warnings because there are so many. We should add something for -pedantic and/or -pedantic-errors to catch more warnings.