Thanks for your very comprehensive reply, Heikki!
> Believe me, everyone involved is painfully aware of this, and we
> have made huge improvements in many areas in a relatively short
I can imagine!
> though, with so many large changes made in the code. Expect better
> after that...
Will do.
> There hasn't been much interest in that. It would need a driver
> who feels strongly for it (you?). I believe it could be quite
I would certainly like to help (it would certainly help my own evaluation of
Mozilla as pointed out in my post) but:
1) I'd need lots of initial assistance from someone else in the form of
start-off pointers - I haven't even looked at the code yet, and if there
are any nice decomposition diagrams, well I havent found them yet! :0)
2) It would have to be a stocking filler to the other demands on my time at
the moment, ie. no firm deadlines for a while.
> Personally I prefer the current model for a *browser
I've seen some real hot debates around on this issue. I was happy with SDI
for my first few browsing years, but when I started using WebSurface (a
great IE wrapper, not really MDI but allowing multiple page windows each
with a tab, of which only one is currently selected at a time) I became a
total convert to the other side. When you're webcrawling for info its just
great to get the search engine results in one window, then pop all the links
you decide to follow into more background windows in the same app, then tab
them to the front one by one. The alternative is total desktop clutter. Even
better, most of the multi-page browsers let you save off the current working
set of pages into a "session" file, and load it better. You can't do that
with SDI (logically, anyway). I'd personally like to see Mozilla get both
features.
> The build process is obviously more difficult than the average
> open source project out there uses. On the other hand, you have
Believe me I totally understand. I once led a large project (not as big as
Mozilla but still hundreds of source files) which had common Unix/Windows
code, but the Windows code was built into dozens of executables of lots of
different types (combos of 16/32 bits, MFC/CLI/plain, C/CPP/VB,
small/medium/large models, DLLs/EXEs/LIBs, PCH/no PCH, debug/normal, RPC
clients and servers, ZIPped stuff, unZIPped stuff, etc) each of which
required different access to MS SDKs (especially the 16-bit stuff, where
there wasnt a single MS SDK covering everything, and one tended to conflict
with the next). The same set of modules also needed to be built into several
different forms. When I joined the project, the build system was a total and
unfathomable mess of makefiles, directories, source files and required
paths.
I ended up doing it by writing an NMAKE wrapper (which knew which files were
required for each executable from a single "database") and a single master
make file (which knew how to build every possible type of thing given a
specification of the source files and a few options). Each subsystem
(executable) then had a tiny little makefile saying what type of thing it
was and which source files were in it, and including the main makefile (not
even any nmake spawns). The order of susbsystem definitions in the
"database" was also the required order for building them all, so my wrapper
just stepped through them one by one in the right order. Net result - a very
nice simple build and config mgmt system, even if the master makefile was
hellishly hard to understand.
Maybe something similar would work for Mozilla (there is an open source
NMAKE, no?), but I'm not familiar enough with the non-WIN32 tools to be able
to do it alone.
> sure that it wouldn't take too much work to make minimal requirements be
> Visual C++ and Cygwin (you'd need to disable JAR
Why would Cygwin still be needed ?
Cheers,
Chris
>
