Heikki Toivonen wrote:
>
> Chris Melville wrote:
>
> > 2) Performance needs to be improved maybe 20-30%. I can't say I noticed much
>
> Believe me, everyone involved is painfully aware of this, and we
> have made huge improvements in many areas in a relatively short
> time frame. The work will continue.
>
> > 3) Its not yet robust enough for something which is supposed to be
> > fairly near completion. I've had numerous start-up and crash problems in my
> > first hour using it, in which I didn't really try anything very complicated.
>
> 0.8.1 has been the most stable milestone release so far, I believe,
> but stability improvements have also been high on our list for
> quite some time. 0.9 is probably going to suck stability wise,
> though, with so many large changes made in the code. Expect better
> after that...
>
> > 4) This is my one "real" gripe:
> > It ** really ** needs a multiple browser window interface (I avoided saying
> > Maybe a sub-project should be spawned to look at this, if there isn't one
> > already.
>
> 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
> a lot of work, but on the other hand I believe it would improve
> the overall quality of the code (breaking some bad assumptions
> etc.)
>
> Personally I prefer the current model for a *browser*. But for
> something like word processing or a development IDE I prefer
> MDI.
>
> I'd like to point out that the current design does not rule out
> MDI-like applications. Look at ActiveState Komodo, for example.
> Komodo lets you open and work with multiple files at the same
> time and they do not open in standalone windows.
>
> > 5) The build process is horrible. I've never known anything need so many
> > tools and emulations to build, and I lost track of all the compile/link
> > warnings spat out (isn't this against the official rules?). I can't help
> > wondering if there's any correlation with 3) above.
>
> The build process is obviously more difficult than the average
> open source project out there uses. On the other hand, you have
> to remember that Mozilla is built on many very different platforms,
> which makes it more difficult to find tools that work basically
> the same way on all platforms, or are even available on all platforms
> Mozilla wants to support.
>
> If you take the Windows build instructions, for example, I am pretty
> sure that it wouldn't take too much work to make minimal requirements be
> Visual C++ and Cygwin (you'd need to disable JAR packaging without
> zip; Netscape wintools and ActiveState Perl would probably be easy
> to get rid of).
wintools.zip is not 'Netscape wintools' The bits in there are
open source; some customized, some with binaries for convenience.
The libIDL and glib parts are critical. Ironically, the binaries
of these are distributed because libIDL is especially painful to
build on Win32 without *exactly* the right 'nix tools in place.
We packaged this zip to make thinks easier, not harder.
John.
> Interested in simplifying the build process? ;)
> About the warnings during build process. We are also aware of them,
> but they aren't high on anybody's list (after all, if it works on
> all our platforms then the warning probably isn't that big a deal).
> In any case, we have warnings listed on the Tinderbox page so
> it is easy to check if something actually is serious. Some of the
> warnings happen because Mozilla wants to support a variety of platforms
> and compilers, which means working around various bugs and quirks in
> the compilers.
>
> Cheers,
>
> --
> Heikki Toivonen
