The interesting thing about this discussion is that it keeps happening
again and again. People see two major differences between Seamonkey and
previous versions of Mozilla: (1) it's slow, and (2) it's themable.
Naturally, they blame the former on the latter, when in fact they're
both caused by something else (XPFE). It's like blaming new-born lambs
on the large number of flowers in bloom, when they're not connected but
caused by the same thing (springtime).
Then, because themability isn't that useful, people get angry that
Mozilla seems to have been made so slow just to introduce a frivolous
feature. So, psychologically, ordinary users might well be happier if
the theme UI was removed, even though that wouldn't speed up Mozilla at all.
Greg Miller wrote:
>
> Aaron Lawrence wrote:
> >
> > OK, I know why... but, given the original Mozilla goals to be very
> > fast and small: aren't skins in complete opposition to that?
> >
> > *Especially* small size!
>
> No, because XUL was needed anyway for portability,
That's the only major reason.
> ease of
> implementation,
Not true. A *lot* of time and effort is being spent reimplementing GUI
controls, and the differing details of how they work on each platform.
One small benefit of XUL and JS is that since the GUI is interpreted
rather than compiled, changes can be tested without waiting for Mozilla
to recompile. The downside is that like any situation where you're
playing off interpreted versus compiled code, interpreted code tends to
be considerably slower.
> and support for non-browser/mail/news applications.
Not true. Plenty of other software vendors have produced programs in the
past 20 years which aren't browsers or mailers, but which don't use XUL.
There's no law which says that you have to use XUL if you're not making
a browser or a mailer.
> > As a general principle, it is basically inefficient (performance,
> > development time, feature completeness, bugs) to redevelop all
> > controls that the native OS provides perfectly well.
>
> No, not really. It cuts development time since you don't have to
> develop separate frontends for each platform.
But if you're going to make Mozilla behave like users expect it to
behave, you do have to develop slightly different front ends for each
platform. Mozilla is doing this with an increasing number of
platform-specific overlays, and (for non-chrome front end details, such
as text selection behavior) prefs which have different default values on
different platforms.
> It's not necessarily any
> slower, since the native OS implements things in software in the first
> place.
>...
Not true. Firstly, Mozilla's GUI is interpreted whereas a native GUI is
compiled. And secondly, Microsoft and Apple have had 15 more years in
which to fine-tune the performance of their GUI code than the Mozilla
programmers have had.
--
Matthew `mpt' Thomas, Mozilla user interface QA
Mozilla UI decisions made within 48 hours, or the next one is free
