Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What are the goals of Mozilla.org?

60 views
Skip to first unread message

Andrew Schultz

unread,
Apr 3, 2004, 8:39:43 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.

http://www.mozilla.org/mission.html
8) mozilla.org is a group chartered to act as the virtual meeting place for
the Mozilla code.

:)

but, ya. I wanna know too.

--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.

Boris Zbarsky

unread,
Apr 3, 2004, 8:42:37 PM4/3/04
to
Robert Mohr wrote:
> I think <http://www.mozilla.org/roadmap.html> covers this fairly well.

No, as a matter of fact it does not. It has tons of verbiage, whereas I
am looking for an answer that should take about 5-6 lines of text, no
more. It also doesn't handle the "what are the relative priorities"
question, which is the important part of what I asked. Finally, the
roadmap page describes what mozilla.org is doing, not what it should be
doing. Or rather, it describes what mozilla.org was doing a year ago.

-Boris

Robert Mohr

unread,
Apr 3, 2004, 8:31:02 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.
>
> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?
>
> Inquiring minds want to know,
> -Boris

I think <http://www.mozilla.org/roadmap.html> covers this fairly well.

--
Robert Mohr
moh...@osu.edu
mo...@cis.ohio-state.edu

Boris Zbarsky

unread,
Apr 3, 2004, 8:28:27 PM4/3/04
to

Benjamin D. Smedberg

unread,
Apr 3, 2004, 8:55:57 PM4/3/04
to
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:

Do you mean "mozilla.org the collective of developers who work on
mozilla", or "mozilla.org the Mozilla Foundation that runs the CVS
server, owns the firefox/mozilla trademarks, and has a few staff members"?

I don't see why various groups of developers cannot order their
priorities as they see fit. The only real problems occur when there is
conflict between priorities, such as the current controversy over
attribute and style reordering.

The role of the mozilla foundation should IMO be primarily service to
users and developers, and should not revolve around marketing.

also, there is no reason why goal #1 in your list could not be "create
several good web browsers", since this is in fact what we already have.

--BDS

Boris Zbarsky

unread,
Apr 3, 2004, 9:10:57 PM4/3/04
to
Benjamin D. Smedberg wrote:
> Do you mean "mozilla.org the collective of developers who work on
> mozilla", or "mozilla.org the Mozilla Foundation that runs the CVS
> server, owns the firefox/mozilla trademarks, and has a few staff members"?

I definitely do not mean the former. I don't quite mean the latter,
though it's closer. I mean what we have passing for project management
(drivers, super-reviewers, mozilla.org staff, etc).

Perhaps a good start is to come up with the list of projects "we"
(whoever that is) have and figure out what their goals are.

> also, there is no reason why goal #1 in your list could not be "create
> several good web browsers", since this is in fact what we already have.

Fine. Like I said, if I'm missing goals, feel free to add them.

-Boris

TenThumbs

unread,
Apr 4, 2004, 7:31:50 AM4/4/04
to
Boris Zbarsky wrote:
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>

All it wants to do is survive. It will use any of your possibilities (and
anything else) as reasons. Right now it's have a hard time because it's
realizing it can't do all the things it once could.

--
Hebe
2004-04-04 11:29:47.555 UTC (JD 2453099.979023)
X = -1.699572719, Y = 1.751356802, Z = 0.675100307
X' = -0.008854341, Y' = -0.005721169, Z' = 0.000304818

Boris Zbarsky

unread,
Apr 4, 2004, 11:13:35 AM4/4/04
to
TenThumbs wrote:

> All it wants to do is survive. It will use any of your possibilities (and
> anything else) as reasons. Right now it's have a hard time because it's
> realizing it can't do all the things it once could.

That doesn't answer my question either. I'm looking for some specifics
from people who are setting mozilla.org policy here.

-Boris

Robert O'Callahan

unread,
Apr 4, 2004, 1:52:58 PM4/4/04
to
TenThumbs wrote:
> All it wants to do is survive.

This just isn't true. Furthermore, it's unfair and insulting.

Many, probably most, of the people involved with the foundation would
make more money with less stress doing something else, and have no
incentive to keep it going for its own sake.

Rob

TenThumbs

unread,
Apr 4, 2004, 1:46:34 PM4/4/04
to
Boris Zbarsky wrote:
>
>
> That doesn't answer my question either. I'm looking for some specifics
> from people who are setting mozilla.org policy here.
>
> -Boris

Their only asset is the mozilla codebase which is a elegantly engineered
product but that elegance requires a large support staff which is now gone and
is unlikely to return. I don't think they know what they can do with it now or
in the future. Difficult times.

--
Flora
2004-04-04 17:45:36.999 UTC (JD 2453100.240012)
X = 1.893180897, Y = 0.141424982, Z = -0.140028831
X' = -0.001584516, Y' = 0.012257855, Z' = 0.004948048

KaiRo - Robert Kaiser

unread,
Apr 4, 2004, 2:04:01 PM4/4/04
to
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:

Do http://www.mozilla.org/about/ and http://www.mozilla.org/mission.html
not provide enough of that? Or not compact enough info?

> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.

The "about" page says "The mission of the Mozilla project is to preserve
choice and innovation on the Internet."

And that's really the base, I'd say from how I see mozilla.org acting.
The goal is not one project (browser/platform/whatever), it's not facing
one competitor, it's choice and innovation.
Of course, the limited resources make that focus to a (well, relatively)
small set of things that can be provided by the Organisation itself.

The "about" document also has a list of things that mozilla.org does. I
basically believe this is nice - perhaps this should be under some other
topic or precised, but I'd think that's bacially it.

Will be interesting for me to hear people of drivers/staff speak on that
issue ;-)

Robert Kaiser

Boris Zbarsky

unread,
Apr 4, 2004, 2:26:59 PM4/4/04
to
KaiRo - Robert Kaiser wrote:
> Do http://www.mozilla.org/about/ and http://www.mozilla.org/mission.html
> not provide enough of that? Or not compact enough info?

Not goal-like enough.

> The "about" page says "The mission of the Mozilla project is to preserve
> choice and innovation on the Internet."

That's so fuzzy as to be useless. It's not a goal one can use to
reasonably set priorities of work. Moreover, it's not a goal that can
be "reached" (it's an ongoing endeavour rather than a target). So there
need to be more reasonable goals that can actually be used to prioritize
work.

I'm not asking a philosophical question, but a project management
question. Perhaps better rephrased as, "What, if anything, should we be
focusing effort on and why?"

-Boris

Chris Hofmann

unread,
Apr 4, 2004, 2:56:10 PM4/4/04
to
KaiRo - Robert Kaiser wrote:

The things written above sum it up pretty well. To preserve choice and
keep the technology relevant we need to do all these things. We need
to create great software that people enjoy using and can use
effectively. We need to maintain and build market share so content
developers have choices to develop interesting and valuable content will
not get sucked into proprietary technologies that lock in businesses and
users to a single provider. We need to promote and seek wide
distribution of the technology in many applications, on many platforms,
and in many languages. We need to foster innovation; both in the way
that people use the web now, and provide ideas and technology that can
improve things and provide choice in the future. The six items Boris
lists above all plug in one way or the other to these goals. We need to
apply good judgment when there appear to be conflicts that arise in
reaching any of the goals or objectives.

It sounds like you have something on your mind Boris. Is there
something that we need to study? Is there something that we need to
consider and apply some good judgment on? Is there some part of the
goals or objectives that seems unclear or out of balance? Are their new
solutions that will help us toward breakthroughs that will allow us to
move faster or more efficiently toward these goals and objectives?

> Robert Kaiser
> _______________________________________________
> Mozilla-seamonkey mailing list
> Mozilla-...@mozilla.org
> http://mail.mozilla.org/listinfo/mozilla-seamonkey


Boris Zbarsky

unread,
Apr 4, 2004, 3:13:07 PM4/4/04
to
Chris Hofmann wrote:
> It sounds like you have something on your mind Boris.

I suppose the thing on my mind is that the project seems to lack clear
goals and clear direction and that project management decisions are
consistently made in an ad-hoc, reactive manner ("oh, no, X finally
happened, must do Y") instead of being made in a proactive manner
("should do Y so that when X happens (as we know it must) we are ready
for it").

The thing on my mind is that as a developer I'm not sure where to apply
my efforts to reduce the chance of them coming into conflict with
Mozilla.org policies, because said policies are always announced at the
very last moment (or indeed sometimes later than that), after claimed
months-long secret deliberations, often without the people affected by
the decisions being consulted or even warned.

The thing on my mind is that I never know when work I put in will
effectively be wasted and that it's not clear what the purpose of me
putting in work is. And most importantly, that I'm not the only one
finding himself in that situation. It's just that so many people have
simply given up on getting any of the above changed.

-Boris

Michael Lefevre

unread,
Apr 4, 2004, 4:02:37 PM4/4/04
to
On 2004-04-04, Chris Hofmann <chof...@meer.net> wrote:
[snip]

> The things written above sum it up pretty well. To preserve choice and
> keep the technology relevant we need to do all these things. We need
> to create great software that people enjoy using and can use
> effectively. We need to maintain and build market share so content
> developers have choices to develop interesting and valuable content will
> not get sucked into proprietary technologies that lock in businesses and
> users to a single provider. We need to promote and seek wide
> distribution of the technology in many applications, on many platforms,
> and in many languages. We need to foster innovation; both in the way
> that people use the web now, and provide ideas and technology that can
> improve things and provide choice in the future. The six items Boris
> lists above all plug in one way or the other to these goals.

But in what way do those things plug into which goals - what are the
timescales on the goals, which are the priorities? If you decide that
you have 20 goals which are all important and everyone should work on
everything all the time, you end up with everyone going off in different
directions, and then you have conflicts and you have to go backwards in
order to try and untangle things.

> It sounds like you have something on your mind Boris. Is there
> something that we need to study? Is there something that we need to
> consider and apply some good judgment on?

The fact that you (staff/drivers) seem to be deciding what the branch
schedule should be, and what kind of things (like API changes?) should go
into the branch, a couple of days before the branch is scheduled to happen
is probably something that most people would think indicated a lack of
planning. The fact that the website still has a roadmap which is nearly a
year out of date, and is still confusing the media and users is something
of an issue.

Mozilla has a bunch of broad and fuzzy aims with indefinite timescales,
and then plans for Seamonkey/Firefox/Thunderbird releases with plans a few
weeks into the future (a bit longer for Firefox/Thunderbird).

In clearly defined project management terms, what are the goals and the
schedule for the next 3 months, 6 months, 12 months? It should be
possible to follow this stuff from a single source, rather than having to
keep up with a bunch of blogs, news sites, newsgroups and forums...

--
Michael

Gus Richter

unread,
Apr 4, 2004, 7:01:35 PM4/4/04
to
Boris Zbarsky wrote:

You are seeking what is what capable companies implement in order to
clarify for all exactly the purpose, goals and method to get there.

Companies have a Mission Statement. Every department has another Mission
Statement. Every departmental division has a Mission Statement. Every
lower level has to keep the upper level in mind. Every lower level
Mission Statement clearly outlines the goal and method. All involvement
at a certain level, must comply with the Mission Statement. The lower
the level, the Mission Statement is more and more pinpointed.

How difficult is it to apply this to Mozilla Foundation? I thought that
with the newly created entity, this would be the first thing that would
be taken care of. It, of course, always depends on upper management's
knowledge and/or abilities. If this method of Mission Statements were
implemented, your questions would clearly be answered. In fact, life
would also be much easier for management.

i.e. Mission Statements for:
Mozilla.org:
Provide the best Browser, the best Mail/News Client, etc ...
Mozilla Browser:
Develop a W3C compliant Browser ....
Moz Browser HTML:
Support all elements per W3C Recommendation with backward compatibility
M-B HTML / Soft Hyphen:
Add full support for Soft Hyphen (&shy;) as IE and Opera do.
etc.

In this simple scenario, a developer intending to work on providing Soft
Hypen support for Mozilla Browser, would have to comply with its Mission
Statement plus all those in the upper levels. Not only does this give
direction for the developer, but other interested parties will know what
to expect. If desiring, for whatever reason, to deviate from the stated
Mission Statement, approval to change the Mission Statement must first
be obtained. Discussion, concerning the request, would alert all
interested parties.

Just my thoughts. Yours?

--
Gus

James Graham

unread,
Apr 4, 2004, 7:10:17 PM4/4/04
to
Chris Hofmann wrote:
>
>>> As the subject says, what are the goals of Mozilla.org? I see
>>> several possible answers:

>>


>>> 1) Create a good web browser. (What definition of good?)
>>> 2) Create a web browser that can successfully compete with IE.
>>> 3) Successfully compete with IE.
>>> 6) Create a platform for delivering apps over the network (not quite
>>> the same as a web browser, but close).
>>> 4) Create an embeddable rendering engine to enable creation of web
>>> browsers.
>>> 5) Create a technology platform on top of which applications (not just
>>> web browsers) can be written.
>>> 6) Something else I'm missing.

>

> It sounds like you have something on your mind Boris. Is there
> something that we need to study? Is there something that we need to
> consider and apply some good judgment on? Is there some part of the
> goals or objectives that seems unclear or out of balance? Are their new
> solutions that will help us toward breakthroughs that will allow us to
> move faster or more efficiently toward these goals and objectives?
>

The conflict between the different goals that Boris mentioned was
plainly apparent in recent discussion at Mozillazine [1] following the
'announcement' that 1.7 is destined to be a stable embedding branch. In
summary, according to Asa, there have been discussions about the
creation of a stable branch for several months but the decision to make
1.7 stable wasn't made until the developer day and wasn't announced
until very recently - after 1.7 went beta. Consequentially developers
have been unable to use the 1.7alpha/beta cycle to make the changes they
feel should be in the next stable branch. It also appears the the
decision that 1.7 should be stable was largely based on the fact that
Firefox 1.0 is going to be released from the 1.7 branch.

This decision clearly conflicts with some of the goals stated above.
Arguably 1) has already been achieved both with Seamonkey and Firefox.
2) will benefit from having a stable base for 1.0 not just because
crashers can be fixed but also because security updates can be released.
In general, one would expect the quality of Firefox 1.0 to increase from
the decision to make 1.7 stable.

On the other hand, the goals relating to /other/ embedders would
generally suffer from this decision. Since people haven't had the
opportunity to get API changes in, embedder are stuck with writing
against substandard code for a year. Therefore, the late decision to
make 1.7 final actively works against goal 5.

Obviously this probably isn't the only thing that Boris had in mind but
it's an interesting example because, had decisions been made proactivley
before 1.6 branched in January there would have been no conflict of
interests. However it appears that the decision was made reactively and
at the last possible moment. Of course, if the goals of mozilla.org
don't encompass the full range of objectives mentioned but only the
first 3 then waiting for Firefox / Thunderbird / Camino to make a
decision on which branch they want to be stable makes a lot more sense.
I assume this isn't the case, but without a very clear idea of what the
actual goals of mozilla.org are (as opposed to the rather nebulous
statements on the website), it's hard to tell if this is simply poor
management or if it reflects the priorities of the organization.

james

[1] http://www.mozillazine.org/talkback.html?article=4544#3

Mooquackwooftweetmeow

unread,
Apr 4, 2004, 7:48:28 PM4/4/04
to
Boris Zbarsky:
vaguely related: bug 233851
http://bugzilla.mozilla.org/show_bug.cgi?id=233851

-- Greg “The Twaddle” Nicholson

Boris Zbarsky

unread,
Apr 4, 2004, 8:18:33 PM4/4/04
to
Gus Richter wrote:
> If desiring, for whatever reason, to deviate from the stated
> Mission Statement, approval to change the Mission Statement must first
> be obtained. Discussion, concerning the request, would alert all
> interested parties.

That sounds very cumbersome for simple day-to-day decisions like "what
will I code today?" by volunteer developers.

Unless I'm misunderstanding you and your scheme would apply to some
higher level of planning?

-Boris

Laurens Holst

unread,
Apr 4, 2004, 9:02:47 PM4/4/04
to
James Graham wrote:
>>>> 1) Create a good web browser. (What definition of good?) 2)
>>>> Create a web browser that can successfully compete with IE. 3)
>>>> Successfully compete with IE. 6) Create a platform for
>>>> delivering apps over the network (not quite the same as a web
>>>> browser, but close). 4) Create an embeddable rendering engine
>>>> to enable creation of web browsers. 5) Create a technology
>>>> platform on top of which applications (not just web browsers)
>>>> can be written. 6) Something else I'm missing.
>
> On the other hand, the goals relating to /other/ embedders would
> generally suffer from this decision. Since people haven't had the
> opportunity to get API changes in, embedder are stuck with writing
> against substandard code for a year. Therefore, the late decision to
> make 1.7 final actively works against goal 5.

About 5), I don't know if it belongs in the list of mozilla.org goals.
The browsers get a lot of attention (so does their extensibility).
However, the XUL and related abilities as a platform doesn't really seem
to be promoted. I have seen some people comment on this with things like
that it is incredibly powerful and a wonderful cross platform
technology, and that the little attention it gets is a shame, but that
seems to be the case.

I have also never seen this 'technology' platform on which applications
can be written. Or I must be missing something big here :). It's at
least nowhere to be found on Mozilla.org's frontpage. So far, when I
want to write an application using XUL, JS and CSS, I have to make it as
an extension of one of the Mozilla products (Firefox / Thunderbird /
Seamonkey).

Compare it with Microsoft's .NET's and its Windows.Forms therein. Say
that I have created an application for it, which I want to distribute as
a full-fledged standalone application. With .NET, I can tell users that
the software only works if .NET has been installed. If it has not been,
I could choose to include a redistributable, but that's of lesser
importance.

In the case of XUL, there is basically no way to do the first (except
from making it an extension of some other product), so we have to do the
second and include the entire platform, which would mean the entire
Gecko engine (not the smallest). And doing this afaik also isn't the
easiest task, as there is no such thing as a ready-made redistributable,
you'll have to extract the Gecko engine from the CVS yourself and set it
up to autorun your XUL app. Or er, something.

Anyways, my 2 cents (or less, if I'm dead wrong here :)).


~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Laurens Holst

unread,
Apr 4, 2004, 9:41:35 PM4/4/04
to
Laurens Holst wrote:
> I have also never seen this 'technology' platform on which
> applications can be written. Or I must be missing something big here
> :). It's at least nowhere to be found on Mozilla.org's frontpage. So
> far, when I want to write an application using XUL, JS and CSS, I
> have to make it as an extension of one of the Mozilla products
> (Firefox / Thunderbird / Seamonkey).
>
> Compare it with Microsoft's .NET's and its Windows.Forms therein. Say
> that I have created an application for it, which I want to
> distribute as a full-fledged standalone application. With .NET, I can
> tell users that the software only works if .NET has been installed.
> If it has not been, I could choose to include a redistributable, but
> that's of lesser importance.

Btw, there might ofcourse be reasons for not wanting to promote XUL &
co. as a platform :)... Aside from the UI stuff something like that also
needs a number of support-functions, amongst others related to security
issues e.d... A platform which is still shaping itself, changing, and
merely used by, developed for and tested with 2 specific products might
not (yet) be fit for use as a full-fledged platform.

It would probably cause many many more enhancement requests, bug reports
and security issues because of the different uses the product is put to.
And if Mozilla is under-staffed, as I understand from other messages,
that may be an extra responsibility they are not willing to take upon them.

That said, now what I'd /really/ like to see is an XUL API for .NET as
an alternative for Windows.Forms... Combined with the rest of the .NET
API (designed for and already existing cross-platform as Mono) it would
offer a very, *very* powerful and cross-platform development
environment. I really like XUL (with its great functionality,
skinnability, ease of editing and L10N abilities), and I really like the
.NET framework (with its great API with many functions for XML, hashing,
file access, e.d.)... you do the math :).

Gus Richter

unread,
Apr 4, 2004, 11:59:13 PM4/4/04
to
Boris Zbarsky wrote:

> Gus Richter wrote:
>
>> If desiring, for whatever reason, to deviate from the stated Mission
>> Statement, approval to change the Mission Statement must first be
>> obtained. Discussion, concerning the request, would alert all
>> interested parties.
>
>
> That sounds very cumbersome for simple day-to-day decisions like "what
> will I code today?" by volunteer developers.

You may be right about being cumbersome, certainly during start-off. I'm
sure that question was posed prior to implementation in companies that
are presently using it. It don't see it helping to decide, but would
provide guidelines.

> Unless I'm misunderstanding you and your scheme would apply to some
> higher level of planning?

It would meet all your concerns from the developer's point of view and
that of management as well. Perhaps there is a better, simpler or
modified way and then there's still the present method. Sorry that I did
not address your concerns directly, but if implemented, this method
would have.

--
Gus

Chris Hofmann

unread,
Apr 5, 2004, 2:27:15 AM4/5/04
to
James Graham wrote:

If you agree with the premise that the freezing of API's won't be
completely resolved in 1.8 and that we would just continue incremental
progress to reaching that goal then the trade off of would be

-some incremental freezing of selected APIs to help reduce the cost of
milestone migration for embeddors
v.
chance for a large bump in distribution across several apps

then I hope the rational for the decision becomes more clear.

We could always choose to wait for more API freezing, More features,
and More bug fixes. If we did so we would never ship releases...

I'm not sure how you define "substandard code", and I'm definitely
unclear about how that relates to the freezing of APIs. Perhaps you
could clarify.

When we freeze API's we generally stamp them as frozen, or we make some
final round of modifications and freeze them. When we do this we
effectively make a contract with the embeddors that they can count on
the interface not changing.

Groups that are embedding mozilla currently use a combination of frozen
APIs and unfrozen APIs. Arbitrary changes to APIs (a bad thing and to
be avoided), or changes that help lead toward the freezing of APIs
(general considered a good thing) both imply some cost to embeddors has
they attempt to migrate or upgrade to a new long lived stable branch.
We definitely want to continue along the road to reducing this cost to
embeddors and reach frozen API nirvana at some point. 1.7 won't be that
point, and it is unlikely that 1.8 would be that point either.

>
> Obviously this probably isn't the only thing that Boris had in mind
> but it's an interesting example because, had decisions been made
> proactivley before 1.6 branched in January there would have been no
> conflict of interests.

Its possible that more progress might have been made to freeze a few
more API's, possibility at the cost of a few fewer crash bug or
compatibility bug fixes. I'm not sure if I agree with the statement
that earlier and better clarity in the communication about 1.7 being a
candidate would have removed all conflicts of interest. There will
always be conflicts of interest, trade offs, and balance to be made on a
project of this size and scope.

> However it appears that the decision was made reactively and at the
> last possible moment.

The decision was made as the result of looking at all the data that we
could gather and digest, and with looking at what we thought was
feasible to accomplish in the next 6 weeks.

> Of course, if the goals of mozilla.org don't encompass the full range
> of objectives mentioned but only the first 3 then waiting for Firefox
> / Thunderbird / Camino to make a decision on which branch they want to
> be stable makes a lot more sense.

Embeddors can be successful in producing applications based on Mozilla.
Many groups are doing this, and more are starting projects to do this.
The plan is to continue to freeze APIs in 1.8, 1.9, and beyond to help
reduce the cost to embeddors as they migrate to new milestone releases.

> I assume this isn't the case, but without a very clear idea of what
> the actual goals of mozilla.org are (as opposed to the rather nebulous
> statements on the website), it's hard to tell if this is simply poor
> management or if it reflects the priorities of the organization.
>

Communication is a two way street. If anyone is confused about how the
goals and objectives of the project relate to specific work they are
doing for either a large scale project, or even individual day-to-day
"which bug should I work on?" questions I would encourage them to flag
down, drivers, staff, or maybe even post to an appropriate newsgroup
for peer feedback. I'm involved in these kind of discussions 30-40
hours a week, and the same could be said for Asa, Brendan and others on
drivers and staff. These discussions influence the decisions that are
made.

One of the tools we used effectively in the past to help roll up key
technical initiatives in the past was the branch landing tool.
http://webtools.mozilla.org/planning/branches.cgi I would encourage
people to start using this tool again.

drivers, can and will, use posting to the branch landing tool, e-mail
updates and questions with pointers to tracking bugs or tasks to help
improve planning and communicate plans earlier and with more clarity to
all interested parties. The criticism about the tardiness of the 1.7
stable branch message is fair and I take full responsibility for it. I
hope it has not, or will not, cause significant problems for any group
or individual, and that the entire project can move forward to try and
make the 1.7 branch the best that it can be.

Thanks

Chris Hofmann

> james
>
> [1] http://www.mozillazine.org/talkback.html?article=4544#3

James Graham

unread,
Apr 5, 2004, 11:51:03 AM4/5/04
to

The problem is not the decision to make 1.7 stable per-se, it's the fact
that the decision was made so late and the fact that no allowance was
made for the puported goals of mozilla.org other than 'create a good
browser'.

> I'm not sure how you define "substandard code", and I'm definitely
> unclear about how that relates to the freezing of APIs. Perhaps you
> could clarify.

I was basing that on what bz said in the mozillazine thread I previously
mentioned. It appears that there was work people wanted to get in before
the next stable branch but which was not completed in the 1.7 cycle
because it was not announced that it would be the next stable branch
until recently.

> When we freeze API's we generally stamp them as frozen, or we make some
> final round of modifications and freeze them. When we do this we
> effectively make a contract with the embeddors that they can count on
> the interface not changing.
> Groups that are embedding mozilla currently use a combination of frozen
> APIs and unfrozen APIs. Arbitrary changes to APIs (a bad thing and to
> be avoided), or changes that help lead toward the freezing of APIs
> (general considered a good thing) both imply some cost to embeddors has
> they attempt to migrate or upgrade to a new long lived stable branch.
> We definitely want to continue along the road to reducing this cost to
> embeddors and reach frozen API nirvana at some point. 1.7 won't be that
> point, and it is unlikely that 1.8 would be that point either.

As far as I can tell, the goal of having being able to create an entire
embedding product from frozen APIs is very distant. I certianly don't
think that 1.8 would have acheived that. However that doesn't mean that
there can't be levels of instability. For example, if one is planning a
major improvement to some API, it might be good to get that in before a
stable branch so minimising the difficulty of maintaining a stable
release and a trunk-based release of a product. If one has several
similar APIs which are being modified to some new way of working, it
might be nice to finish those changes before a stable branch so that
developers don't have to spend a lot of time learning differences
between the APIs that will vanish with the next milestone.

>> Obviously this probably isn't the only thing that Boris had in mind
>> but it's an interesting example because, had decisions been made
>> proactivley before 1.6 branched in January there would have been no
>> conflict of interests.
>
>
> Its possible that more progress might have been made to freeze a few
> more API's, possibility at the cost of a few fewer crash bug or
> compatibility bug fixes.

Possibly, but more likely, at the expense of a few non-critical feature
requests or other enhancements. In any case, crash bugs can be fixed
after beta, major pieces of code cannot.

My central point is, if the organisation had communicated to developers
that 1.7 was going to be stable and that several embeddors were planning
to release of 1.7, they could have prioritized work as they saw fit.
Instead, it looks like the decision was made with regard only to the
needs of the embeddors and without consideration for the people working
on the core. I assume that isn't actually the case but it's not clear.

> I'm not sure if I agree with the statement
> that earlier and better clarity in the communication about 1.7 being a
> candidate would have removed all conflicts of interest. There will
> always be conflicts of interest, trade offs, and balance to be made on a
> project of this size and scope.

Sure :) But better communication from drivers about the criteria on
which decisions are made (the goals of the project) and about the
decisions themselves can reduce those tradeoffs dramatically since
people know what to expect and can work around problem areas.

> The decision was made as the result of looking at all the data that we
> could gather and digest, and with looking at what we thought was
> feasible to accomplish in the next 6 weeks.

But why only 6 weeks? It must have been clear for a long time that
either 1.7 or 1.8 would be stable. In light of the fact that there are ~
3.5 seamonkey milestones per year, I would expect the next stable branch
(released in summer 2005) to be 1.10 or 1.11, based on past history. I
believe that Camino and Firefox were making plans at the end of January
to release from 1.7. Given that these plans were clearly a large factor
in the eventual decision, it seems reasonable that it could have been
made before 1.6 branched for release.

> drivers, can and will, use posting to the branch landing tool, e-mail
> updates and questions with pointers to tracking bugs or tasks to help
> improve planning and communicate plans earlier and with more clarity to
> all interested parties. The criticism about the tardiness of the 1.7
> stable branch message is fair and I take full responsibility for it. I
> hope it has not, or will not, cause significant problems for any group
> or individual, and that the entire project can move forward to try and
> make the 1.7 branch the best that it can be.

Obviously, I want people to try and make 1.7, and all the subsequent
work on the project as good as it can be. Of course, this relates
somewhat to people having a clear idea what is percieved as being 'good'.

Chris Hofmann

unread,
Apr 5, 2004, 3:58:57 PM4/5/04
to
James Graham wrote:

> Chris Hofmann wrote:
>
>>
[snip]

>
> The problem is not the decision to make 1.7 stable per-se, it's the
> fact that the decision was made so late and the fact that no allowance
> was made for the puported goals of mozilla.org other than 'create a
> good browser'.
>

Again, I apologize for not working to get this message out earlier.

>> I'm not sure how you define "substandard code", and I'm definitely
>> unclear about how that relates to the freezing of APIs. Perhaps you
>> could clarify.
>
>
> I was basing that on what bz said in the mozillazine thread I
> previously mentioned. It appears that there was work people wanted to
> get in before the next stable branch but which was not completed in
> the 1.7 cycle because it was not announced that it would be the next
> stable branch until recently.
>

It may or may not have been appropriate on this case, but drivers always
has, and always will, encourage engineers to send mail to discuss areas
of work that are on the verge of not making making an alpha or beta
cycle for consideration in landing very early after a tree closure.
This is a case by case evaluation and we often take things late in the
development cycle that can significantly improve the milestone release,
and still offer a good deal of comfort that we can shake out any
problems associated with landings at the end of the development cycle.
I hope that all people working on the project understand this and
continue to use this to get help in landing important stuff at the end
of cycles.

[snip]

>
> But why only 6 weeks? It must have been clear for a long time that
> either 1.7 or 1.8 would be stable. In light of the fact that there are
> ~ 3.5 seamonkey milestones per year, I would expect the next stable
> branch (released in summer 2005) to be 1.10 or 1.11, based on past
> history.

Again I apologize. There are no good excuses here. Only poor ones
about trying to get too many things done on too many fronts, and
dropping the ball on a very important task.

I should say that we have a need to to at least one major release per
year we we try to align most of the organizations building on top of and
distributing mozilla to work together to make it significantly better
and more tested than others, if that has not been said before or is not
well understood. So much good work goes on in the course of the year
that should get those improvements to the widest distribution possible.
For example 1.7 has 20-30% page loading performance improvement over
1.4, and footprint requirements also have great improvements. The list
of improvements is long when you look at the things that have been
accomplished over the last year. We need to get all the major Linux
distros and others to move up to 1.7 and start getting the improvement
in the hands of their users.

Mozilla 1.0 Shipped in June 2002 and Mozilla 1.4 Shipped in June 2003 so
if your looking at past history June is a good month for trying to meet
the needs of distributors...

[snip]

James Graham

unread,
Apr 5, 2004, 6:05:43 PM4/5/04
to
Chris Hofmann wrote:
> Again I apologize. There are no good excuses here. Only poor ones
> about trying to get too many things done on too many fronts, and
> dropping the ball on a very important task.

Chris, thanks for taking the time to respond, it's very much
appreciated. I certainly have very high hopes for the products being
released off the 1.7 branch :)

L. David Baron

unread,
Apr 5, 2004, 7:38:58 PM4/5/04
to
On Saturday 2004-04-03 19:28 -0600, Boris Zbarsky wrote:
> As the subject says, what are the goals of Mozilla.org?

I think an interesting question to ask before that is: where should
mozilla.org's goals come from? I think the source of goals should be
from mozilla.org's contributors (of all types), since at the most basic
level mozilla.org is an organization that allows people to collaborate
on projects that they could not do themselves. This implies a few
things:

a. Its good we're having this discussion.

b. Some of these goals, or their requirements, or their requirements'
requirements (etc.) may in turn require paying attention to the
goals (and their requirements) of people who aren't contributors.
The main example of this is that contributors may want their work to
be used by as many people as possible, either for its own sake, or
to help fulfill some other goal they have (such as helping to keep
the web based on open standards). This implies that we should pay
attention to the goals of distributors of our software and of
potential contributors.

Thinking of this in terms of goals and requirements probably isn't the
best idea, since it treats goals and requirements as binary when they
aren't. But given that this discussion is framed in terms of goals
rather than utility, and I've already written most of this message
before realizing that it's the wrong framework, I'll stick with that
framework until the last paragraph.

> I see several possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.
>
> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?

Here's another question: should mozilla.org be in the business of
defining its goals? Perhaps, instead, it should (A) provide a forum for
people to state their case for various goals, and (B) try to mediate
when the goals come into conflict. However, as a practical matter, many
of the goals *do* conflict, so (B) probably requires that mozilla.org
actually define its goals. And the relative priorities of the goals
certainly conflict. So probably mozilla.org does need to define its
goals.

An example might be useful here. My main goal is to keep the Web
developing towards a universal system for access to information, which I
think requires that it be based on open standards. Thus I care about
our support for standards and I care about making Mozilla usable on the
Web. Doing this often has much smaller bugward-compatibility
requirements than maintaining a technology platform on which
applications can be written. I think it would be good for the web (for
reasons I won't go into here) to develop the XUL box model into
something that is usable as a web standard. If I were to work on this,
mozilla.org's current rules *might* require that I maintain more
backwards-compatibility than is necessary to keep our current
applications running, or that I fix up mozilla.org applications that are
in our tree that I don't care about. Should I be required by
mozilla.org to care about things like this that I don't care about
personally, or should the people who do care about it be required to fix
it (or provide a backwards-compatibility layer) if I break XUL
backwards-compatibility? And how should mozilla.org decide whether I
should be required to do so?


To try to answer a small part of your original question: I already said
that my main goal is to keep the Web developing towards a universal
system for access to information, which I think requires that it be
based on open standards. Thus I care about what you called (4), and I
care about anything else that leads to the product of (4) being used
more widely on the Web, which I think leads to (variants of?) (1), (2),
and (3) being requirements.

But that's speaking for myself only, and I'd be surprised if more than a
few other contributors agreed with me.

(It's also worth noting that I've avoided complicating this discussion
with issues of my goals vs. my employer's goals. I don't think that
makes the underlying issues any more complicated, it just makes
describing them more complicated. And when I refer to my goals above,
I'm talking about my personal goals, not the goals I have because
they're my employer's goals.)


Then there's the issue of what requirements would help meet that goal.
Or, more clearly stated, what would increase my utility as defined by
that statement. Lately, I've been having trouble finding good answers
to that question, since I've been having trouble thinking of attainable
goals that I believe could have a noticeable change in the expected
utility.

-David

--
L. David Baron <URL: http://dbaron.org/ >

Ben Goodger

unread,
Apr 5, 2004, 11:49:11 PM4/5/04
to Boris Zbarsky
Boris Zbarsky wrote:

> I suppose the thing on my mind is that the project seems to lack clear
> goals and clear direction and that project management decisions are
> consistently made in an ad-hoc, reactive manner ("oh, no, X finally
> happened, must do Y") instead of being made in a proactive manner
> ("should do Y so that when X happens (as we know it must) we are ready
> for it").

I would tend to agree. In some ways it's easy for my project since I
have a fairly clearly defined sub-roadmap that estimates timelines and
general zones of work between now and July/August or so this year. But
in the wider sense I (and others) are curious about where the platform
is going. There's been much talk about "Mozilla 2.0" in the past year
and what it must do to effectively deal with some of the new API
challenges that are emerging. There's been very low level talk about a
number of specific changes to functionality that exists presently
without a view of medium-long range goals, but not a great deal (at
least that I've heard, and I've asked many of the sources) of higher
level stuff outlining what the important projects are that need to be
accomplished before we can have a "2.0". By higher level I don't mean
executive summaries - I mean identified projects and project plans.

It might seem like I'd only be interested in 1, 2 and 3 because of my
role, and while those are certainly primary interests of mine, 5 and the
first 6 are also interesting, but specifically 5. It's something I've
given a great deal of thought to in the past, and a place where I
believe there may be lucrative opportunities in the future. There are
many challenges that still need to be overcome before Mozilla technology
can compete at the same level as other platforms, and an understanding
of what people think "2.0" means is central to that, in my mind.

I hate to sound like a project manager, but I think that's what's needed
here.

1) Mozilla will (at least for the short-mid-term future, as far as I can
tell) be about creating a web browser
2) ... and about a mail solution (we have to keep the lights on).
3) If we want a platform for building apps (and 4 may be a subset of 6),
and that effort is one of the targets of a 2.0, we need to do some
things - identify what it means to be a next generation platform (that
means not targeting GTK/GNOME today, Windows 2000 or XP SDKs as they are
today, but what they're doing next), divvy that task up into sections
and get resources allocated, estimates - work plans. There's been so
much talk about this lately that I feel my head is going to explode. So
much talk, so much hand waving, so few plans.

-Ben

Brendan Eich

unread,
Apr 6, 2004, 1:43:50 AM4/6/04
to Boris Zbarsky
Boris Zbarsky wrote:
> [Posting to this newsgroup for lack of a better one; if there is a more
> appropriate place, please feel free to set Followup-To accordingly.]
>
> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.
> 6) Create a platform for delivering apps over the network (not quite
> the same as a web browser, but close).
> 4) Create an embeddable rendering engine to enable creation of web
> browsers.
> 5) Create a technology platform on top of which applications (not just
> web browsers) can be written.
> 6) Something else I'm missing.


(I'm going to refer to this second item 6 as (7) below.)


> These are not mutually exclusive, of course. Which of these are actual
> goals (as opposed to accidental byproducts), and what are their relative
> priorities?
>
> Inquiring minds want to know,


Thanks for writing -- you're asking exactly the right questions. Some
of what I write below follows from the slides I presented at Developer
Day (http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/).

I liked dbaron's followup where he brought up "utility", something from
the Dismal Science that hints at the true nature of our problem
(scarcity, subjective value). Goals and requirements sound all
scientific, or bureaucratic. Life isn't that simple, but people often
would rather it were; Armies are great simplifiers, in this sense.

Mozilla is not the Army. That's the good news. The bad news is that we
have Redmond's army ants arrayed against us. We need strong leadership
*and* external allies, if we are to preserve much of the utility
(however subjectively valued) of open standards.

Mozilla can't be a laissez-faire anarchy where staff just resolves
conflicts, because we face not only built-in conflicts, but what's more,
competition from aggressive monopolies and near-monopolies. Although
Mozilla code will be around for many years, it may become increasingly
irrelevant without two things:

A. Browser user agent market share.

B. *Useful, efficiently implementable, easily authored* open standards
co-evolved with killer applications, such that those standards compete
with counterparts in the proprietary systems (Windows Longhorn,
Macromedia Flex, etc.).

If we do only "the browser thing" (1-3 from your list of goals), we are
likely to be irrelevant in approximately five years. Not unused, but
trailing-edge; not built upon as a platform, not invested in even as a
hedge. Yet (1-3) are necessary, even if not sufficient.

Note that (2) and (3) may imply, for certain enterprises and reprobate
sites, supporting the IE DOM, Active X plugins, and other things we'd
rather not support. If we don't support some of these things, we may
not in fact succeed in competing with IE enough to get sufficient (A).

Why will we likely be irrelevant without more than a good web browser?
The answer is involved; bear with me.

First, Longhorn formats such as XAML will leak onto the web, satisfying
your goals (5-6). We can predict this with high confidence based on the
IE4 experience. In 1997, IE4 shipped a better browser, with
non-standard CSS bugs, DOM quirks, and DHTML features, and of course
things like Active X. By 2000, when IE was crossing the 50% market
share barrier, sites were (intentionally or not) restricting
interoperation to IE clients only.

Another Windows predictor: Windows XP took ~2.5 years to pass 40%
according to Google zeitgeist.

Second, Linux is poised to rise just by being cheaper. "Total Cost of
Ownership" compared to Windows is hard to assess currently, with many
variables, confounders, and hidden costs on both sides. Some experts
claim Windows has lower TCO right now. But assume Linux improves and
wins. This seems a fairly safe prediction, as predictions go --
especially in other parts of the world.

The problem I foresee is that Linux may very well not ship a default
Mozilla browser, relegating Gecko to the category of web-content engine,
soon to be "legacy" web content engine. In this light, we might make
(4) an anti-goal. Given trends in at least the GNOME world, the likely
result of the default-browser decision favoring a GNOME browser is that
GNOME/Linux desktops and apps evolve to compete with Windows Longhorn by
solving roughly the same problems in different ways (Mono or no Mono).

The long-term result would be not only a lack of cross-platform apps --
there would be a lack of new cross-platform contents and protocols
needed to countervail XAML and other Longhorn formats, protocols, and
languages. We can see the beginning of this fragmentation, although not
along OS lines so much as proprietary client lines, with Flex from
Macromedia, Laszlo's XML-based language, and similar children of XUL
from the "rich internet application" platform players.

If Miguel and company clone XAML and Avalon (the harder part to clone),
perhaps in three years Linux will be able to match most of what we can
see coming in Longhorn in the way of open-standards-threatening content.
But that content will still be relatively or completely closed, under
the control of Microsoft, subject to revision at its discretion. Not a
pretty picture, even if Mono *eventually* helps apply de-facto or even
de-jure standardization pressure.

What seems worse, though, is the likelihood that XML-based content types
might proliferate and speciate along platform lines: some for Linux,
others for Windows. Without cross-platform browsers implementing the
same standards everywhere, including the new, non-legacy, ones, the
likelihood of interoperation bugs and outright incompatible/non-portable
formats grows.

In all this, I'm discounting the Mac. It's an important and influential
niche, one that Mozilla values, but not one likely to grow enough to
make a difference compared to Linux and Windows. If the OS and
especially the multimedia apps were to be ported to PCs and opened up to
developers on other platforms, maybe -- but those steps would undercut a
lot of Apple's profitability, its platform's strengths, and its appeal
(yes, including its snob appeal).

Here's an alternative that I'm working hard to promote:

I. Build cross-platform apps from the ground up, using Gecko, native
theme-based rendering, and good desktop/OS integration.

II. Promote these apps, starting now -- think Mozilla-the-suite,
Firefox, Thunderbird, Open Office -- on Windows, especially in
enterprises that wish to avoid lock-in, virus hazards, and high license
fees.

III. Let those enterprises migrate to Linux if it makes sense, or defer
the hefty Longhorn upgrade tax by sticking with downrev Windows for as
many years as makes sense.

IV. At the same time, starting now and working closely with other open
source hackers, build a new, unified desktop/web application platform
from pieces of Mozilla and GNOME code, starting now. Share code and
effort; avoid big rewrites. Use standards where possible, including the
parts of XUL that are being specified now. This new platform might even
deserve the "Mozilla 2.0" title.

This new platform must include an advanced rendering layer with hardware
acceleration, fancy effects, animation, video, etc. We should use what
works now, with as much cross-platform leverage (OpenGL), filling in
gaps on some platforms, and again (always) avoid long-pole scheduling
dependencies where the entire subsystem must be rewritten.

Another characteristic of this new platform: high-level programming
language independence, with a good choice of "managed code" runtimes
(Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming.
We must not keep losing fingers and toes to C and C++; that approach
is a money loser compared to .NET.

A crucial features of this new platform: the GUI toolkit must be able to
blend in among native apps, at least on Windows and Linux, ideally on
Mac too. There should be a well-specified XML syntax and semantics for
creating user interfaces (XUL) and graphics (SVG or something like it,
but unified), and for composing tags from DOM trees (XBL). There must
be a low-cost migration path from XUL today to this future language.

I've been busy laying groundwork, building bridges between different
open source projects. It's still too early to say exactly how things
will turn out. I don't want to make promises that I can't keep, and a
lot of planets have to align still. But there is interest among other
key projects' leaders. I think a number of smart folks see the need for
alliance against the hegemon.

This platform play would address (5-6) by marrying, as much as allying,
GNOME, Mozilla, and perhaps Mono -- bringing cross-platform code and
development to the Linux side, and native next-generation GNOME look and
feel to Mozilla. It would build something we've been unable to build in
a compelling or complete way by ourselves: a development platform for
arbitrary third party web and desktop apps.

The time frame for this plan is now, with working code by 2nd half of
this year. Otherwise we're sliding into next year, in danger of being
too late to gain mindshare before Longhorn's inevitability wins the day
for XAML, etc. So, if this is to succeed, we have major concurrent
development challenges ahead.

I'll answer any questions I can here, and I encourage all comments. If
something in the analysis above rings false, please say what and why. If
you're following up just one point, feel free to change the subject to
start a sub-thread.

/be

Axel Hecht

unread,
Apr 6, 2004, 8:32:09 AM4/6/04
to
Brendan Eich wrote:

<...>

I'd like to note that there is a pretty nice talk by Tim O'Reilly about
"paradigm shift". He basically said that single-computer-apps wont win a
thing in the future and that control over the wire will determine market
share. He used the term "commodity software" quite a lot, mostly talking
about LAMP on the server side. But IMHO, Mozilla is an important part of
commodity software in this scheme as well. And Tim didn't oppose to
that. Not sure if he would have dared, he just broke his one arm ;-).


>
> Here's an alternative that I'm working hard to promote:
>
> I. Build cross-platform apps from the ground up, using Gecko, native
> theme-based rendering, and good desktop/OS integration.

How far are we done here? 20% or 80%?

> II. Promote these apps, starting now -- think Mozilla-the-suite,
> Firefox, Thunderbird, Open Office -- on Windows, especially in
> enterprises that wish to avoid lock-in, virus hazards, and high license
> fees.
>
> III. Let those enterprises migrate to Linux if it makes sense, or defer
> the hefty Longhorn upgrade tax by sticking with downrev Windows for as
> many years as makes sense.
>
> IV. At the same time, starting now and working closely with other open
> source hackers, build a new, unified desktop/web application platform
> from pieces of Mozilla and GNOME code, starting now. Share code and
> effort; avoid big rewrites. Use standards where possible, including the
> parts of XUL that are being specified now. This new platform might even
> deserve the "Mozilla 2.0" title.
>
> This new platform must include an advanced rendering layer with hardware
> acceleration, fancy effects, animation, video, etc. We should use what
> works now, with as much cross-platform leverage (OpenGL), filling in
> gaps on some platforms, and again (always) avoid long-pole scheduling
> dependencies where the entire subsystem must be rewritten.

How much manpower do we have for cross-platform-widget code these days?

> Another characteristic of this new platform: high-level programming
> language independence, with a good choice of "managed code" runtimes
> (Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming.
> We must not keep losing fingers and toes to C and C++; that approach is
> a money loser compared to .NET.
>
> A crucial features of this new platform: the GUI toolkit must be able to
> blend in among native apps, at least on Windows and Linux, ideally on
> Mac too. There should be a well-specified XML syntax and semantics for
> creating user interfaces (XUL) and graphics (SVG or something like it,
> but unified), and for composing tags from DOM trees (XBL). There must
> be a low-cost migration path from XUL today to this future language.

On the aspect of XBL, that needs a security model. And maybe other
things, as Alex Fritze felt forced to invent xtf,
http://www.croczilla.com/xtf

Changing the toolkit will open the fundamental point that dbaron
mentioned in his previous post. Who's doing the work.
(/me lays back and waits for glazou's rant.)

> I've been busy laying groundwork, building bridges between different
> open source projects. It's still too early to say exactly how things
> will turn out. I don't want to make promises that I can't keep, and a
> lot of planets have to align still. But there is interest among other
> key projects' leaders. I think a number of smart folks see the need for
> alliance against the hegemon.
>
> This platform play would address (5-6) by marrying, as much as allying,
> GNOME, Mozilla, and perhaps Mono -- bringing cross-platform code and
> development to the Linux side, and native next-generation GNOME look and
> feel to Mozilla. It would build something we've been unable to build in
> a compelling or complete way by ourselves: a development platform for
> arbitrary third party web and desktop apps.
>
> The time frame for this plan is now, with working code by 2nd half of
> this year. Otherwise we're sliding into next year, in danger of being
> too late to gain mindshare before Longhorn's inevitability wins the day
> for XAML, etc. So, if this is to succeed, we have major concurrent
> development challenges ahead.

That timeframe seems, say, very optimistic. "Timeframe now" in general
is a quarter too late, which made Boris start this thread.
OK, a month late for those working full time. But for contributors and
esp for modules without any full time staff, I think a quarter is closer.

> I'll answer any questions I can here, and I encourage all comments. If
> something in the analysis above rings false, please say what and why. If
> you're following up just one point, feel free to change the subject to
> start a sub-thread.
>
> /be

On a general note:
This post is pretty much worth two or three postings to
http://weblogs.mozillazine.org/roadmap/. And it's good to see at least
some of the vision of one of those doing the decisions in the end.
But let's keep in mind that a good direction with noone there to go
might do more harm than good. I see very good reasons for some aspects
of the Mozilla project being managed top-to-bottom, but as this thread
indicates, sometimes the bottom wonders who at the bottom is supposed to
implement the decisions.

On the edge on all of this, don't forget that some folks try to make a
living off the Mozilla platform. Their business plans rise and fall with
the decisions made here (and not here).

Axel

KaiRo - Robert Kaiser

unread,
Apr 6, 2004, 1:55:12 PM4/6/04
to
> build a new, unified desktop/web application platform
> from pieces of Mozilla and GNOME code, starting now.

I still think that it's a shame that Mozilla project is ignoring KDE
(and the other way round). Konqueror/KHTML seem not to be reason enough
for me to be that ignorant. This looks to me as it may lead to a massive
split with some Linux distributors and a big community user, as many of
them strongly support KDE.
OTOH, we need to focus on working on something, and we can't let
ourselves get split up into working on too many different things. And as
GNOME people have no good web browser but Gecko-based products, it's the
logical thing to do. If we really want an alliance of OSS projects to
win, we should not ignore that half of the Linux desktops (or more) are
not on GNOME but KDE, and we only can achieve good support of the OSS
communities by integrating with that as well, IMO.
We may not build everything with KDE in a "unified platform" - but we
should be able integrate much, much more. We're losing market on Linux
if we don't, I fear.

Robert Kaiser

Asa Dotzler

unread,
Apr 6, 2004, 2:01:05 PM4/6/04
to
James Graham wrote:

> believe that Camino and Firefox were making plans at the end of January
> to release from 1.7. Given that these plans were clearly a large factor
> in the eventual decision, it seems reasonable that it could have been
> made before 1.6 branched for release.

1.6 branched _in December_. If Firefox and Camino (and other projects)
were just beginning to converge on 1.7 at the _end of January_, how
could any decision have been made before 1.6 branched in December? In
addition to all of our other work, we're supposed to have invented time
travel, too?

--Asa

Brendan Eich

unread,
Apr 6, 2004, 2:20:39 PM4/6/04
to Axel Hecht
Axel Hecht wrote:
> Brendan Eich wrote:
>
> <...>
>
> I'd like to note that there is a pretty nice talk by Tim O'Reilly about
> "paradigm shift". He basically said that single-computer-apps wont win a
> thing in the future and that control over the wire will determine market
> share. He used the term "commodity software" quite a lot, mostly talking
> about LAMP on the server side.


This was at OSCON last summer, right? I was there, but I think that
keynote echoed things Tim had said elsewhere. Maybe you meant a
different talk, say http://tim.oreilly.com/p2p/FOSDEM.pdf?


> But IMHO, Mozilla is an important part of
> commodity software in this scheme as well. And Tim didn't oppose to
> that. Not sure if he would have dared, he just broke his one arm ;-).


http://primates.ximian.com/~miguel/tmp/two-stacks.png


Still, Mozilla is not a platform first -- it has been, intentionally, a
platform second, in order to build certain apps first.

I'm suggesting that we must keep building killer apps, but also partner
with other open source projects, in order to build a more coherent
platform that can withstand what's coming in Longhorn. And better yet,
be the base for new apps that we and others build, to do the kind of
collaborative networking, shared browsing, and pervasive computing that
Tim talks about.


>> Here's an alternative that I'm working hard to promote:
>>
>> I. Build cross-platform apps from the ground up, using Gecko, native
>> theme-based rendering, and good desktop/OS integration.
>
>
> How far are we done here? 20% or 80%?


For item II, below, we are at least 80% -- we can promote Firefox to
enterprises when it reaches 1.0, which will be some time this summer, if
all goes as planned. The Mozilla suite is already used by enterprises;
the "1.0" for both it and the platform it was built on was 2 years ago.
Thunderbird is right behind Firefox.

Implied but not stated in my original post was the idea that by building
a new platform with GNOME and others, with a clear migration path from
today's Mozilla platform, we could then bring up Firefox and Thunderbird
on the new platform, next year.


> How much manpower do we have for cross-platform-widget code these days?


More than a few paid developers in the Mozilla and GNOME worlds, if the
alliance can be pulled off. Many more volunteers from both communities.
The manpower problem is eased, not made worse, by alliance with other
projects.


> On the aspect of XBL, that needs a security model. And maybe other
> things, as Alex Fritze felt forced to invent xtf,
> http://www.croczilla.com/xtf


It seems to me (Alex, please jump in here) that XTF addresses different
requirements than XBL. I like XTF, though (but its name hurts my hands,
especially when I've been typing Xft lately ;-). I'd like to hear some
comments from content and layout folks (bz, dbaron, jst) on whether they
think it would be advisable to land the branch soon and support XTF by
default.


> Changing the toolkit will open the fundamental point that dbaron
> mentioned in his previous post. Who's doing the work.
> (/me lays back and waits for glazou's rant.)


More than just us in our Mozilla bunker; that's the idea, anyway.


> That timeframe seems, say, very optimistic. "Timeframe now" in general
> is a quarter too late, which made Boris start this thread.


Sorry, can't be helped. Better now than later. The problem is that we
haven't yet joined forces at an operational level with GNOME hackers.
To do that requires more negotiation on details with project leadership.


> On a general note:
> This post is pretty much worth two or three postings to
> http://weblogs.mozillazine.org/roadmap/.


Good idea, I'll update that. I'm not used to blogging, but posting to
newsgroups isn't that far from blogging.


> And it's good to see at least
> some of the vision of one of those doing the decisions in the end.
> But let's keep in mind that a good direction with noone there to go
> might do more harm than good. I see very good reasons for some aspects
> of the Mozilla project being managed top-to-bottom, but as this thread
> indicates, sometimes the bottom wonders who at the bottom is supposed to
> implement the decisions.


The 1.7-as-stable-year-long-release-branch decision should have been
announced earlier, but I don't think I could have said much about the
GNOME/Mozilla alliance earlier without lying. Even now, I'm not sure
how things will play out, but I'm convinced that to be a complete and
compelling platform, we need more than what we ourselves can do.
Specifically, we need the blessings of "native-ness" on Linux, as well
as "managed code" runtime support and programming language neutrality
(or good plurality), and killer hardware accelerated graphics.

I'm glad you pointed out http://www.croczilla.com/xtf, which I'd glanced
at the other week while looking at jssh. I think Mozilla needs the kind
of high-leverage hacking shown there. Hacking useful new things on top
of Mozilla-the-platform should not be that hard. It's getting easier if
you know the right fulcrums to use.

We do need to hide details where the implementation will have to change,
and where we plan to do incremental rearchitecture (reflow, line
breaking, etc. in layout, e.g.). We need a bit more symmetry and
completeness in the code, and a lot more documentation (DevMo, see the
threads at news://news.mozilla.org/netscape.public.mozilla.documentation
and stay tuned for an update).


> On the edge on all of this, don't forget that some folks try to make a
> living off the Mozilla platform. Their business plans rise and fall with
> the decisions made here (and not here).


That reminds me: whatever future toolkit with XML syntax comes from the
alliance being forged with GNOME and other projects, and also from the
standardization efforts in the w3c, Mozilla will keep compatibility with
XUL 1.0 and XBL 1.0, possibly unbundled so minimal "2.0" apps don't have
to carry the weight if they don't need it.

The only sure way to keep compatibility is to leave the old code as
untouched as possible. So the new platform work will have to be done
beside the current gfx, widget, and xul widget layers, by implementing
existing interfaces, introducing new ones used only conditionally, etc.

More on the operational details and tasks in a bit.

/be

us...@domain.invalid

unread,
Apr 6, 2004, 2:39:33 PM4/6/04
to
KaiRo - Robert Kaiser wrote:

I use KDE all the time. If Mozilla didn't actually WORK in KDE I'd have
to do something about it.

As far as Qt integration goes, there is no barrier to someone building
gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
integration into Mozilla. No-one has volunteered to do it, and no
companies seem interested in doing it. So it hasn't been done.

Rob

Laurens Holst

unread,
Apr 6, 2004, 3:29:48 PM4/6/04
to
Wonderful text. I'm looking forward to this, really. I voiced some of my
opinions on issues like this a few messages ago, and this sounds like
the ideal solution ^_^.

Furthermore, I read this article yesterday:
http://ometer.com/desktop-language.html

You probably already know it, but for those who don't, it forms a nice
background to this and the discussion and concern apparantly (and
rightfully) forming in the opensource community about the possibility of
starting to lag behind on modern technologies (in particular: OO
programming languages with garbage collection and JIT, etc).

That article sounds more in favour of Java than Mono, and I find that
somewhat of a shame as I really dislike developing in Java. Let's just
say I always have to fight to get things working, while in the contrary
.NET (/ Mono) has been a breeze :). However, that is mostly an API
problem, I think. XUL is a big improvement over what both environments
have to offer, UI-wise. For the Visual Studio addicts, an UI designer
tool would make XUL even more accessible to people.

Let's hope this proposed platform will offer lots of easy-to-use
functions in a wide range, and provide the nessecary shorthands when
they come in handy for actual development purposes. .NET does a good job
at this, and I hope this platform you are suggesting will do an even
better job, and then *truly* cross-platform :). Oh, and let's not forget
to introduce revolutionary new technologies, instead of following in
M$'s wake. Or at least it seems a little like that right now :), panic
all around because of fear of falling behind (and not unrightly so).

Anyways, I'm no active developer in this area (I'd rather stick to my
small personal projects :)), but I'm looking forward to what is going to
happen the next few years. Interesting times :).

L. David Baron

unread,
Apr 6, 2004, 3:56:52 PM4/6/04
to
On Tuesday 2004-04-06 14:39 -0400, us...@domain.invalid wrote:
> As far as Qt integration goes, there is no barrier to someone building
> gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
> integration into Mozilla. No-one has volunteered to do it, and no
> companies seem interested in doing it. So it hasn't been done.

The first two have been done. However, the code wasn't maintained, so
it was removed from the tree.

Brendan Eich

unread,
Apr 6, 2004, 6:25:20 PM4/6/04
to Axel Hecht
Axel Hecht wrote:
> Brendan Eich wrote:
>
>> Here's an alternative that I'm working hard to promote:
>>
>> I. Build cross-platform apps from the ground up, using Gecko, native
>> theme-based rendering, and good desktop/OS integration.
>
>
> How far are we done here? 20% or 80%?


The longest pole for the 1.0 apps is the "good desktop/OS integration",
particularly GNOME integration and GTK theme-based rendering. The bug
tracking this work is http://bugzilla.mozilla.org/show_bug.cgi?id=233462.

For most of the work items, we can buy by the yard, so to speak, up till
near the last freeze date for Firefox 1.0, without adding too much risk.

Please jump in and offer to help on the unfixed dependencies of this
bug. bryner and p_ch could surely use the help.

/be

Robert O'Callahan

unread,
Apr 6, 2004, 8:48:28 PM4/6/04
to
L. David Baron wrote:
> On Tuesday 2004-04-06 14:39 -0400, us...@domain.invalid wrote:
>
>>As far as Qt integration goes, there is no barrier to someone building
>>gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
>>integration into Mozilla. No-one has volunteered to do it, and no
>>companies seem interested in doing it. So it hasn't been done.
>
>
> The first two have been done. However, the code wasn't maintained, so
> it was removed from the tree.

Yeah, well I wasn't about to bring that up :-). It was never done *well*.

Rob

Dennis McCunney

unread,
Apr 7, 2004, 12:21:12 AM4/7/04
to
Brendan Eich wrote:

> I'll answer any questions I can here, and I encourage all comments. If
> something in the analysis above rings false, please say what and why. If
> you're following up just one point, feel free to change the subject to
> start a sub-thread.

Brendan, thanks for the analysis and reply.

Allow me to toss in a few thoughts of my own, because I've been thinking
about the issue as well.

Ultimately, this is about *marketing*.

The legendary management consultant Peter F. Drucker once said "The job
of business is to *create* a market". To do so, you need to understand
who the customer is, and what the customer needs. In many cases,
success will be a result of filling a need the customer didn't realise
she had until your particular widget was there to do whatever it does.

A lot of Open Source development I see reminds me of the late, lamented
Digital Equipment Corporation, run by engineers, producing cool
technology with what products might be made using the technology as an
afterthought. DEC isn't with us any more, and there are reasons for
that. Another horrible example might be Xerox Corp., with a habit of
creating great technology that someone *else* made into a killer
product. Without Xerox PARC, the Star workstation, and Smalltalk, we
wouldn't have the Mac *or* Windows, with mice and bit-mapped GUIs, but
Xerox never made a commercial success of the developments they
pioneered, and while Xerox is still with us, it has problems.

A lot of open source development is done by hackers working on cool code
without any real concept of who will *use* what they write.

The first question I would ask is "What is Mozilla?"

The answer *used* to be "Netscape's code name for the rewrite of
Netscape Communicator to produce a product that could compete with
Internet Explorer". That's not true any more. Netscape formally
divested itself of Mozilla.

I've seen well-reasoned arguments elsewhere that Netscape was barking
mad to toss out the existing Navigator code base and go for a ground-up
rewrite. Among other things, it took three years for the first fruits
of that labor to get out the door, whereas refactoring and enhancing the
existing code might have been done a lot sooner.

Also, to be able to create the browser they wanted, the Mozilla
developers first had to create a new set of tools and technologies they
could use to accomplish what they wanted. They did so, and the results
have been stunning.

I would call that set of tools and technologies Mozilla, and the Mozilla
browser simply one product that was created with it.

If I were marketing Mozilla, I wouldn't push the browser as the end
product. I'd push what I used to *create* the browser, and use the
browser as a real world example of what Mozilla can be used to create.

The second question I would ask is "Who is the customer?"

Back when Mozilla was still a Netscape funded effort to create the next
generation browser, that question was easy: the customer was Netscape,
and Netscape's vision of what *thier* customers wanted shaped the
requirements for the product.

Microsoft succeeded because there was a clear vision of what they were
building and who would use it. While there were doubtless internal
debates in Redmond about *how* to accomplish certain goals, they had
goals, based upon thier conception of who thier customers were, and what
thier customers would *pay* for.

Who are Mozilla's customers? Mozilla used to repeatedly say that the
actual Mozilla releases were for testing and development purposes, and
not intended for use by end-users. The assumption was that if you were
an end-user, you probably wanted the Netscape browser built on top of
the Mozilla code base.

Netscape is no longer the driver here, and more and more end-users *are*
using Seamonkey (or Firefox/Thunderbird), so Mozilla *is* now an
end-user product. But I don't think the Mozilla planning or development
process has truly grasped that yet. How many critical bugs are ignored,
or useful features unimplemented, because they aren't important or sexy
enough to the developers who would have to do it, and the developers
aren't focused on the needs of the end-users?

I'd split Mozilla.org's mission into two parts.

One would focus on polishing and refining the browser and other
components, because these are the real world examples of what can be
done with Mozilla technology, and it's in Mozilla's interest for as many
people as possible to be using them. The first group's customer would
be the end users.

The second part would focus on developing and extending the tools and
technologies used to created the browser. The second group's customers
would be other developers, looking for a better way to create
applications for end users.

I'd be a customer for both, but I'd have different needs.

As an end user, I use Mozilla as my production browser. I need it to be
fast and stable, and I need it to be easily extensible to handle tasks
related to it's primary mission. That mission, for me, is information
retrieval and storage. So I want the code base to settle, and I want to
be able to do things like install an extension, expect it to work in
either Mozilla or Firefox, and be able to disable or uninstall it if needed.

As a developer, I am looking for Mozilla based tools I can use to
develop applications for end-users. I'm a Unix SysAdmin for a living.
I support a number of non-technical users who access my servers to run
production applications. They don't know anything about the servers
they access, or about Unix, and they don't want to and shouldn't have
to. One of the things I've been thinking about is GUI front-ends on PCs
connecting the the production application on the back end, and giving
the users something more intuitive than a shell command prompt to work
with. CSS, XUL, and Javascript strike me as a perfect way to do that.

If I had a lot of money to fund a development effort, I'd pay someone to
write a GUI, drag-and-drop application builder that would generate CSS,
XUL and Javascript to create front-ends that would talk to server
applications on the back end, and free folks like me to define the
communications with the back end app and the interface between it and
the GUI.

Mozilla can solve a number of my problems, but only if the folks
creating Mozilla understand what my problems are. Multiply me by
(potentially) millions, and you define the challenge Mozilla faces.

> /be
______
Dennis

Daniel Glazman

unread,
Apr 7, 2004, 4:02:32 AM4/7/04
to
Boris Zbarsky wrote:

> As the subject says, what are the goals of Mozilla.org? I see several
> possible answers:
>
> 1) Create a good web browser. (What definition of good?)
> 2) Create a web browser that can successfully compete with IE.
> 3) Successfully compete with IE.

> 4) Create a platform for delivering apps over the network (not quite


> the same as a web browser, but close).

> 5) Create an embeddable rendering engine to enable creation of web
> browsers.
> 6) Create a technology platform on top of which applications (not just


> web browsers) can be written.

> 7) Something else I'm missing.

(the above items renumbered since your original numbering was bad)

Part of (7) is certainly "Create a platform for rich content editing".
This covers in-browser-editing (formerly known as Midas) and content
editors like Composer, Nvu, XML editors, XUL editors, ...
I am speaking for my own chapel only here, of course. That's why I
say "part of 7".

(2bis) is certainly "Create a mail user agent that can successfully
compete with OE". (3bis) is "Successfully compete with OE".

Please note that 2bis and 3bis could be MUCH EASIER to achieve
than 2 and 3... A lot of companies and governmental orgs are dropping OE
in favor of Mozilla because of security. Email is much more a
concern for sysadmins than the browser.

From my perspective, your items above are far too browser-centric.
Each time we have thought in a browser-centric way, we have introduced
improvements in the code that were bad for other apps.

The browser is the main application of the Mozilla platform, that's
for sure. But if we keep only that one in mind, we'll fail delivering
a platform to other applications' builders.

Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
We've not even started. Maybe MozFound should contract with Nigel
McFarlane and write with him the official Mozilla Technologies Embedding
Guide, sold as a book. I am very serious here.

Just my 2 eurocents.

</Daniel>

Axel Hecht

unread,
Apr 7, 2004, 4:13:29 AM4/7/04
to
Brendan Eich wrote:

> Axel Hecht wrote:
>
>> Brendan Eich wrote:
>>
>> <...>
>>
>> I'd like to note that there is a pretty nice talk by Tim O'Reilly
>> about "paradigm shift". He basically said that single-computer-apps
>> wont win a thing in the future and that control over the wire will
>> determine market share. He used the term "commodity software" quite a
>> lot, mostly talking about LAMP on the server side.
>
>
>
> This was at OSCON last summer, right? I was there, but I think that
> keynote echoed things Tim had said elsewhere. Maybe you meant a
> different talk, say http://tim.oreilly.com/p2p/FOSDEM.pdf?

I was listening to the talk at the FOSDEM.


>
>
> > But IMHO, Mozilla is an important part of
>
>> commodity software in this scheme as well. And Tim didn't oppose to
>> that. Not sure if he would have dared, he just broke his one arm ;-).
>
>
>
> http://primates.ximian.com/~miguel/tmp/two-stacks.png
>
>
> Still, Mozilla is not a platform first -- it has been, intentionally, a
> platform second, in order to build certain apps first.
>
> I'm suggesting that we must keep building killer apps, but also partner
> with other open source projects, in order to build a more coherent
> platform that can withstand what's coming in Longhorn. And better yet,
> be the base for new apps that we and others build, to do the kind of
> collaborative networking, shared browsing, and pervasive computing that
> Tim talks about.

What I was wondering for a bit, how much money do his friends like
amazon et al spend on getting their UI working in incompatible browsers?
If it'd be significant, we could get an ally or two over there.

Axel

Daniel Glazman

unread,
Apr 7, 2004, 4:10:09 AM4/7/04
to
Daniel Glazman wrote:

> Last point: ...

Sorry for spam, I forgot a _major_ point that Boris did not list:

"Successfully enter the mobile devices market with Minimo"

This item is _major_ for two reasons:

1. there is a place for Mozilla there
2. we can compete with Opera there
3. that's certainly for MozFound a good way of getting funds...
4. it forces us to think in terms of reduced footprint and perf
improvements, and that's good for the desktop apps too

</Daniel>

Axel Hecht

unread,
Apr 7, 2004, 4:15:38 AM4/7/04
to
us...@domain.invalid wrote:

Without any knowledge on how we hook up the toolkit, could we make that
pluggable? I bet the question cannot be "Gnome or KDE", but how to do
both with one installation.

Axel

Axel Hecht

unread,
Apr 7, 2004, 4:43:23 AM4/7/04
to
Daniel Glazman wrote:

<...>

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.

Well, we have started. Fantasi and Nigel head the devmo-drivers, and
though there is no content yet, we do have a start.

Of course, this is no paper work, at all. Not sure if any of the stuff
we're doing is reusable on paper. And I myself wouldn't focus on it to
start with, just because online documentation is a higher priority. And
online and paper docs just work completely different.

Axel

Benjamin D. Smedberg

unread,
Apr 7, 2004, 7:58:08 AM4/7/04
to
Daniel Glazman wrote:
> Part of (7) is certainly "Create a platform for rich content editing".
> This covers in-browser-editing (formerly known as Midas) and content
> editors like Composer, Nvu, XML editors, XUL editors, ...

Here here! In order for any reasonable "mozilla the platform"
application to succeed, we need to remember two functions that the
browser uses only sparingly: editing and printing. If we end up with a
great platform that can't do either of these, in the end we lose.

--BDS

fantasai

unread,
Apr 7, 2004, 9:10:29 AM4/7/04
to
Axel Hecht wrote:
>
> Well, we have started. Fantasi and Nigel head the devmo-drivers, and
> though there is no content yet, we do have a start.

Actually, Myk's doing most of the work, setting up infrastructure.

~fantasai

KaiRo - Robert Kaiser

unread,
Apr 7, 2004, 9:27:02 AM4/7/04
to
>> As far as Qt integration goes, there is no barrier to someone building
>> gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
>> integration into Mozilla. No-one has volunteered to do it, and no
>> companies seem interested in doing it. So it hasn't been done.
>>
>> Rob
>
> Without any knowledge on how we hook up the toolkit, could we make that
> pluggable? I bet the question cannot be "Gnome or KDE", but how to do
> both with one installation.

There was talk about that once, and it seems that it may be doable, but
as Qt support died, the question grew irrelevant.

I know there are people who'd like to help with doing a new Qt port
(actually there's no real use in reviving the old work, it seems, it has
to be redone completely, perhaps taking some ideas from the old work).
From time to time, talk arises about that in the still-existent
n.p.m.qt newsgroup, but as noone comes up to lead the work (should
ideally understand our framework and know Qt as well), it always dies again.
As with many things, we'd need a project leader (module owner) there,
then the project could take off easily on a branch/mini-branch.
I offered to be checking in work of people without CVS access on that
branch, and doing test builds from time to time.

Robert Kaiser

Heikki Toivonen

unread,
Apr 7, 2004, 2:26:19 PM4/7/04
to
Boris Zbarsky wrote:
> 6) Something else I'm missing.

Besides the mobile platform that was mentioned by Glazman, I feel we'd
really need more tools. Or maybe just one too, the killer XUL GUI builder.

We already have several very succesfull tools. The most well-known are
the webtools (Bugzilla at the front), but DOM Inspector and the JS
Debugger are pretty good.

On the GUI builder front, we have some external projects that seem to be
starved of resources. Microsoft has traditionally been very good a
providing good tools, and I feel our lack of a great, well-known GUI
builder is holding us back. Imagine a Visual Basic - or even Visual C++
- developer of 5 years hearing all this rant about the greatness of XUL
and the Mozilla platform deciding to give it a go, only to find that he
would need to hand edit cryptic XML files to get a simple dialog app
with a couple of buttons running!

--
Heikki Toivonen

Bogdan Stroe

unread,
Apr 7, 2004, 2:40:24 PM4/7/04
to
Heikki Toivonen wrote:

There is a proposal to integrate a Mozilla XUL builder into Eclipse IDE.
See http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/

Bogdan

Brendan Eich

unread,
Apr 7, 2004, 5:17:07 PM4/7/04
to Axel Hecht
Axel Hecht wrote:

>> I'm suggesting that we must keep building killer apps, but also
>> partner with other open source projects, in order to build a more
>> coherent platform that can withstand what's coming in Longhorn. And
>> better yet, be the base for new apps that we and others build, to do
>> the kind of collaborative networking, shared browsing, and pervasive
>> computing that Tim talks about.
>
>
> What I was wondering for a bit, how much money do his friends like
> amazon et al spend on getting their UI working in incompatible browsers?
> If it'd be significant, we could get an ally or two over there.


That browser compatibility problem won't go away any time soon, though.
IE is stagnant and it will be used for many years to come. We don't
know whether and how the Longhorn browser engine has been fixed, or not,
to match w3c specs -- I would guess "not".

So even if Firefox had big distribution deals, sites such as Amazon
would need to sweat browser compatibility for a long time yet.

/be

Brendan Eich

unread,
Apr 7, 2004, 5:12:40 PM4/7/04
to Daniel Glazman
Daniel Glazman wrote:

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.


You haven't been reading n.p.m.documentation, probably -- Nigel is
involved, he's one of devmo-...@mozilla.org.

/be

Nigel McFarlane

unread,
Apr 7, 2004, 8:39:28 PM4/7/04
to

> Last point: items 5 and 6 imply a TREMENDOUS effort on documentation.
> We've not even started. Maybe MozFound should contract with Nigel
> McFarlane and write with him the official Mozilla Technologies Embedding
> Guide, sold as a book. I am very serious here.

I'm open to all such things, but the MF & I have plenty of mutual
work at the moment. Nothing suit me better than writing on Mozilla,
unless it's arguing with Bugzilla denizens.

Calling all lurking Mozilla embedders: drop me an email if this
missing doco is hurting you; there's always a way forward.

regards, Nigel.

Nigel McFarlane

unread,
Apr 7, 2004, 10:00:25 PM4/7/04
to

I've read a lot of this thread. I don't really
care what Mozilla.org's stated goals are. I'm more
interested in what futures are practical and possible,
and what we say about ourselves to others.

Some points from me:

A. Popularity is worth nothing.

In all this discussion I only see Popularity as an
implied end-goal. Popularity by itself is a hollow value.
What, if anything, are we trying to do other than look
good in the mirror? To be in it for popularity
alone is no better than being in it for money alone.

This thread is no place for a political argument,
I merely point out that by itself, popularity is not
enough. If there are to be goals (an open question)
thay should be framed in terms of a better ideal, and
popularity relegated to the status of a tool or a tactic.
I have no beef with popularity as a tactic.

For Mozilla's Web offering we have this spirit in
place, at least in one form, when we talk about
preserving access to the Web for all people through
support for public standards.

We don't have a similar spirit in the broader context
of mozilla-the-technology. We need one.

"Mozilla: enabling free application software".

B. Mozilla lives in an Information Vacuum

DevMo will in part address this, but I should point it
out for those who've missed it. Mozilla as a technology
is highly disconnected from both the broader grass-roots
technology community, and from the product marketting
environment. This, more than anything, (as some other
posters here have complained) is limitting and slowing
the development of this technology.

At the marketing level, current brand management goes
no further than to market Mozilla as a point solution:
email and Web. This is a two-edge sword: we need to express
what mozilla products are, but this expression also
dumbs down and distracts from the fine technology underneath.

We need a "Mozilla Inside" plan, and we need to stop
having the problems that Macromedia had with their poorly
named Shockwave and Flash offerings.

Firefox: a great Web browser. Mozilla Inside.

Because of this lack, mozilla-the-technology labours badly
under questions such as "what is it?" and "what are the
goals of Mozilla.org?". Hence this thread.

At the grass-roots technology level, we are an island.
It is no coincidence that xulplanet uses an island metaphor
for its website. We need to get down and dirty with
all the other open and closed source programming communities,
from Perl and C++ to visual basic. This is a DevMo goal as
far as I'm concerned.

C. No one needs another complex OO framework

We have Java. We have Mono. We have C++. Any attempt
to make Mozilla another complex OO framework suitable for
high-level programmers is a waste of time.

It makes far more sense for Mozilla to aim at beginner
and intermediate programmers, who currently have no
FOSS offerings except the wierd syntax of Tcl, the
hackery of Perl and ports of Visual Basic. JavaScript has
a far cleaner syntax than any of these. Anyone who thinks
C# is stolen purely from Java is crazy. It's also stolen
from JS.

Mozilla-the-technology brings apparent simplicity
to programmers via HTML, JS, CSS, XML and simple uses of
XPCOM. That simplicity should be preserved.

Our highly talented contributors with extensive grasp of
OO, delegation and frames as programming constructs
have done a grwat job of boiling some of that down for the
vast majority of ordinary programmers.

In my view that is a core value we should preserve at all
cost. Lots of programers just can't do Java, even after
they're trained, and they are an audience for us.

D. What you've got is what you are.

Despite the constraint of C., our talented contributors
are producing a very sophisticated information engine.
It's been tuned, refactored, optimised, trimmed and bundled
to the finest detail. We should be justly proud of its
complexity and power, and shouldn't stop it.

I see in Brendan's post that he advocates a classic
"conflate two or more ideas to grow something new" strategy.
That's well and good, but we also have core values.

I propose that the answer to the question: "What is Mozilla?"
is this:

Within Open Source, Mozilla is the application kernel.

The linux kernel is deeply informed by hardware. Mozilla-the-
technology is deeply informed by data: XML, datacomms, display,
storage and objects. These are all application-level issues that
live on top of OS services. We should be proud to be in the
applicaiton space.

Mozilla-the-technology is big enough and ugly enough,and optimised
enough and detailed enough to call itself the application kernel.

E. But you can be more.

Brendan's ideas of conflating open source tools make sense,
but here's a note of caution. It is a huge task to develop
application domain-specific expertise. I have spent years in
the Telco event management field, and just grasping the
requirements of that single niche is the work of a lifetime.

To take on a domain beyond web and email/messaging at this
stage is suicide. We must stay focussed on tools, not
application domains.

Bringing together point E (tools), C (simplicity) and
Brendan's points, the challenge I see is for the
Gtk/Mozilla tools to leap way ahead of existing tools.

I recently read this:

"People have an expectation that replacing [xxx] with a commercial GUI
that has a GUI builder will save a lot of effort. However, GUI
programming effort usually consists of spending about 5 percent of the
time using the visually appealing drag-and-drop GUI builder. The other
95 percent of the time is still spent coding the underlying display
logic. Therefore, replacing UIX may not realize as much benefit as desired."

Clearly Longhorn is no improvement on this. But Mozilla's
new offerings and future direction could be.

regards, Nigel.

Doug Turner

unread,
Apr 8, 2004, 12:54:38 AM4/8/04
to Daniel Glazman

I am sure that I can not comment on the all of goals of mozilla,
but as for Minimo... Minimo is one of the most important fronts that
the Mozilla.org has. (okay, well maybe I a bit bias.)

Last I read, Linux currently makes up about 3% of the desktop and the
same for the consumer mobile markets. The linux usage or adoption rate
is increase much faster in the mobile market. More people are seeing
linux for devices as the obvious solution. Major manufacturers are
shipping linux on consumer devices such as the Sharp Zaurus. Linux
replacement OS's are reaching the point that non-geeks can use then
productively.

Many browsers in this space are limited that simple dhtml pages file to
layout. Others are huge memory consumers making them impossible to run
over the simplest page cycles. Minimo beat these browsers hands down.

Most of the goals of Minimo were shared by Mozilla. The majority of our
initial work was footprint and modularization. I think a goal of
Mozilla should be to foster continued work to make Mozilla smaller in
both disk footprint and memory usage. We have made allot of progress!
Mozilla owners should have a goal of minimizing footprint and making the
product as modular as possible so that we can remove optional component
for 'lite' projects such as Minimo.

With that said, Minimo needs more than that... We face some problems
that most of the traditional Mozilla user dont have. One of the obvious
problems is that most web pages and our client ui is designed for at
least 640x480. We need to think of better ways to make browsing such a
site not only do-able, but enjoyable. Glazman has done some excellent
work in the content area and has release a SSR extension for Mozilla,
kudos!.

Products like firefox have a chance on some of the high end mobile
device if its UI could notice that the resolution is too small and so
something smart. Right now, running the suite or the ng clients run
fine on many ARM devices but they are simply unstable since much of the
app ui isnt viewable.

Random needs|goals of Minimo in no particular order:

* Minimo needs to be running on QT. I have gotten many request for a QT
version of Minimo. If you know how to fix this port and have the time,
lets talk.

* Minimo needs UI love. We need some minimalistic eye candy.

* Minimo needs people to help identify code that can be removed if we
don't want it. For example, maybe you know about some code that we have
to handle some obscure or not frequently used feature. Tell me about it.

* Minimo needs some UI GTK help. If you have some time to do some gtk
hacking, please drop me a note. I have a few small tasks that I would
love to hand off.

Regards,
Doug Turner

Matthew Thomas

unread,
Apr 8, 2004, 2:03:42 AM4/8/04
to
Brendan Eich wrote:
>...
> The problem I foresee is that Linux may very well not ship a default
> Mozilla browser, relegating Gecko to the category of web-content
> engine, soon to be "legacy" web content engine.

(Disclaimer: I was one of those consulted on whether Galeon or Mozilla
should be GNOME's default Web browser. Epiphany vs. Firefox 1.0 would be
another interesting contest.)

>...
> The long-term result would be not only a lack of cross-platform apps
> -- there would be a lack of new cross-platform contents and protocols
> needed to countervail XAML and other Longhorn formats, protocols, and
> languages.

Throughout this you seem to be assuming that any alternative to XAML
needs to be cross-platform. But from what I have read, XAML is not
cross-platform; it is intended to produce applications that will make
sense on Microsoft Windows. Even if those applications can be run on
other platforms, they will be ugly and inconsistent on those other platforms.

In competing with XAML, it may be that you think cross-platform-ness is
part of the solution. I hope you also consider that it may be part of
the problem. Trying to work on multiple platforms may mean working
poorly on all of them.

>...


> Here's an alternative that I'm working hard to promote:
>
> I. Build cross-platform apps from the ground up, using Gecko, native
> theme-based rendering, and good desktop/OS integration.

In general, the more cross-platform a graphical application is, the less
desktop/OS integration it will have. (Prominent examples include Mozilla
1.x on every platform, Java desktop apps on most platforms, and
Microsoft Word 6.0 on the Mac.)

This is far from a perfect correlation; it is easy to make applications
that are equally horrible on multiple platforms! But it is very hard to
make applications that are a joy to use on multiple platforms.

As an example, consider the standard methods of configuring an
application on each platform.

MS Windows GNOME Mac OS X
---------------------------------------------------------------------
Menu location "Tools" "Edit" <app name>

Item title "Options..." "Preferences..." "Preferences..."

Keyboard combo (none) (none) Command+,

Window modal yes no no

Minimizable no yes no

Window title "Options" "<app name> title of currently
Preferences" selected panel

Navigation tabs tabs toolbar

Buttons "OK", "Cancel" "Close" (none)

Changes happen after "OK" instantly instantly

---------------------------------------------------------------------

Perhaps you can see that if someone implemented a standards-compliant
cross-platform configuration interface using XUL, it would be a minor
miracle. It would not be something we could expect all, or even most,
application developers to achieve.

There are many other examples. MS Windows, GNOME, and Mac OS X have
different terminology, different horizontal alignment of controls within
a window, different preferred methods of separating unrelated controls,
different approaches to empty space in tabbed windows, different forms
of error notification, different approaches to what is important enough
to appear in a toolbar, different controls for adding/removing items in
a list, still-different controls for adding/removing items in an option
menu, different controls for showing/hiding advanced settings in a
window, different system-reserved keyboard combinations, different
preferred interfaces for presenting help, and different subsets of
settings that are presented in the platform's global configuration
interface and should therefore not be in the configuration interface of
an individual application.

You might expect these differences to be decreasing over time, but
they're increasing. Mac OS X's interface is more different from MS
Windows than Mac OS 9's interface was. And GNOME's interface is also
diverging from MS Windows, as GNOME develops its own design style.

>...


> A crucial features of this new platform: the GUI toolkit must be able
> to blend in among native apps, at least on Windows and Linux, ideally
> on Mac too.

>...

None of the differences I have listed can be fixed using themes. A few
can be fixed using sufficiently complicated overlays. But surely at some
point even that becomes more difficult than just designing for one
platform at a time.

--
Matthew Thomas
http://mpt.net.nz/

Matthew Thomas

unread,
Apr 8, 2004, 2:05:49 AM4/8/04
to

Brendan Eich

unread,
Apr 8, 2004, 3:27:56 AM4/8/04
to Matthew Thomas
Matthew Thomas wrote:
>
> Throughout this you seem to be assuming that any alternative to XAML
> needs to be cross-platform.


No, I *argued* that cross-platform is the best way to keep open
standards both interoperable and relevant, because user-agent market
share matters, and because standards are under attack by single-platform
purveyors.

I made a second argument, that Linux market share is poised to rise more
than other non-Windows platforms, and that Mozilla has the best chance
of gaining the most distribution by riding that tide (but that we are
also at risk of losing distribution deals in the short run by not having
sufficiently native-looking UI).

I made a third argument, that Windows to Linux migration is aided by
making certain high-use apps cross-platform ("think Mozilla-the-suite,
Firefox, Thunderbird, Open Office").

Please pay attention.


> In competing with XAML, it may be that you think cross-platform-ness is
> part of the solution. I hope you also consider that it may be part of
> the problem. Trying to work on multiple platforms may mean working
> poorly on all of them.


Mozilla apps apart from Camino are cross-platform, and they have better
and worse integration quality and consistency according as the platform
has any consistent HIG, widget kit, and user-base that cares. They have
other values, of course; not everyone cares as much as you do about HIG
consistency (assuming there is a HIG).

My belief is that we can do a lot better, especially on Linux where we
need to in order to win distribution, by converging GTK+ and Gecko's XP
widgets, which already use nsITheme-based native rendering. I freely
admitted that the Mac is a hard case, although some users (Jon Udell,
e.g.) don't give a fig about Firefox not being a Cocoa app.

I'd like to point out that the top ten killer apps on Windows, the ones
that make it a compelling platform more than any HIG or UI consistency
ever could, are a mess as far as UI consistency goes. Mom and Pop, and
the Photoshop and Dreamweaver users, do not care enough to shun the
low-cost hardware platform.

Notice that Linux targets that same commodity hardware.

Perhaps Linux should be a bit more consistent and shiny than Windows,
but any argument of the form: "to beat Windows, first make a uniform,
uber-consistent UI across all apps and the desktop" is false on its
face. What Linux needs first, and most, are killer apps (and things
like a HAL, which Project Utopia may deliver -- but I digress).


> This is far from a perfect correlation; it is easy to make applications
> that are equally horrible on multiple platforms! But it is very hard to
> make applications that are a joy to use on multiple platforms.


That's true. However, we hear from many people (not you, but you don't
count ;-) that Firefox is a joy to use on Windows and Linux, with a
vocal but no doubt smaller cohort on Mac testifying likewise.

This isn't just worse-is-better bragging. Mozilla intentionally favors
cross-platform, even when it means native integration suffers or lags.
The reasons are to uphold interoperable open standards and to assist
incremental, app-wise/app-before-kernel migration off of Windows, or any
other platform that becomes costly or risky due to lock-in monopoly.


> As an example, consider the standard methods of configuring an
> application on each platform.
>
> MS Windows GNOME Mac OS X
> ---------------------------------------------------------------------

> [snip]


> Buttons "OK", "Cancel" "Close" (none)
>
> Changes happen after "OK" instantly instantly
>
> ---------------------------------------------------------------------
>
> Perhaps you can see that if someone implemented a standards-compliant
> cross-platform configuration interface using XUL, it would be a minor
> miracle. It would not be something we could expect all, or even most,
> application developers to achieve.


I think you really ought to catch up on Mozilla's OS-theme-based native
look integration before surfacing after so long (almost two years in
this newsgroup) and raising issues already being fixed, if not already
fixed.

Also, it seems to me the table you made does not represent the platform
state of the art accurately: e.g., GNOME uses Cancel and OK or another
Affirmation label, in that order, nowadays; see
http://developer.gnome.org/projects/gup/hig/1.0/windows.html#dialog-layout.
Try any recent Mozilla app on a GNOME 2.x system. Notice also the menu
rendering.

I already mentioned the tracking bug for GNOME integration; here it is
again: http://bugzilla.mozilla.org/show_bug.cgi?id=233462.

As GNOME improves its file picker and print dialogs, we are quite happy
to use them and to dispense with our XUL alternatives, which we shipped
(at least in the file picker case) because the native counterpart was so
deficient. We have bugs on file and people working on using these new
and improved native dialogs.

Things will only get better, especially if we can merge our efforts with
GNOME's.


> There are many other examples. MS Windows, GNOME, and Mac OS X have
> different terminology, different horizontal alignment of controls within
> a window, different preferred methods of separating unrelated controls,

> [snip]


Yes, I know. That's why we (a) use nsITheme-based rendering where we
can; (b) consider using native dialogs, especially on platforms whose
distribution we crave; (c) work hard and don't make big bucks.

We have made a conscious trade-off in preferring XP to native UI. That
means inconsistency and hard work to fix the glitches. Duh! But doing
native UI means at least 3x the work up front, followed immediately by
platform disparities, and consequent interoperation hazards.

Now we're trying to converge XP and native UI on GNOME, to partner for
better distribution and a better total platform.

At the same time, we aim to keep our XP UI on Windows at least as
well-integrated as it has been. There are widgets on Windows, such as
tabs, that have no theme-based rendering support that we know of on XP.
We could use native tabs, but at some cost that's probably high enough
not to be worth it -- Mom and Pop, and most users, simply do not care.

On the Mac, we will suffer by pickier users' lights until a Cocoa/Quartz
hacker steps up and helps our XP widgetry use the right APIs. Pickier
users may prefer Camino, and we continue to support it for them.


> None of the differences I have listed can be fixed using themes.


I don't think you are using theme in the same sense that I used. See
http://lxr.mozilla.org/mozilla/search?string=NS_THEME_.


> A few
> can be fixed using sufficiently complicated overlays. But surely at some
> point even that becomes more difficult than just designing for one
> platform at a time.


Here you are the one ass-u-ming. Go try native front-end development
some time. A bunch of us have, over four+ releases of Netscape
products, as well as in past lives.

Please try to accept that we are, by executive decision and general
consensus, committed to XP UI for the Mozilla platform. Therefore we
are not going to integrate perfectly on platforms where integration is
less vital to users and (what's more important for success on some
platforms) to leaders and influencers, for whatever reason.

If you don't like this decision, wait a few years and maybe it will
become clear that you were right. But don't try to smuggle your
conclusion in with "surely" -- nothing here is obvious, let alone
sufficiently certain to make such assertions.

/be

Gervase Markham

unread,
Apr 8, 2004, 3:49:59 AM4/8/04
to
Nigel McFarlane wrote:

> A. Popularity is worth nothing.

I don't agree. Popularity (in terms of use) is worth a bunch of
webmasters taking notice, many more non-IE-only websites, and a nicer
user experience for all Gecko users.

> C. No one needs another complex OO framework
>
> We have Java. We have Mono. We have C++. Any attempt
> to make Mozilla another complex OO framework suitable for
> high-level programmers is a waste of time.

I think that several companies building on the Mozilla platform would
disagree with you. C++ isn't all that cross-platform, and not without a
recompile. Java UI sucks - even Swing's not great, and the JVM is
enormous. Each has its drawbacks. Sure, Mozilla has a different set, but
for some companies, it hits the spot.

Gerv

Daniel Glazman

unread,
Apr 8, 2004, 4:03:58 AM4/8/04
to
Brendan Eich wrote:

> You haven't been reading n.p.m.documentation, probably -- Nigel is
> involved, he's one of devmo-...@mozilla.org.

Excellent news :-) So my original proposal was not so crazy ;-)

</Daniel>

Daniel Glazman

unread,
Apr 8, 2004, 4:15:25 AM4/8/04
to
Brendan Eich wrote:

> That browser compatibility problem won't go away any time soon, though.
> IE is stagnant and it will be used for many years to come. We don't
> know whether and how the Longhorn browser engine has been fixed, or not,
> to match w3c specs -- I would guess "not".

Remember IE is not the future of Microsoft. I think you can expect more
and more Tasman-everywhere in a quite near future.

a. Microsoft has built Tasman on more platforms that Mozilla (dixit
MSFT themselves, and I tend to believe them...)
b. Tasman is almost certainly the next-gen browser on mobile devices
powered by MSFT
c. Tasman is already used in digital TV projects, MSN for Mac
d. Tasman is much more standards compliant than MSIE's engine

There is one thing I learned about Microsoft: they can surprise us.
And on this particular subject, they have a lot of cards in hand...

</Daniel>

Stranger

unread,
Apr 8, 2004, 6:08:22 AM4/8/04
to
I saw this suggestion in gnomedesktop.org:
------
XAML is winning largely on hype at the moment, but then so did WWW.
The greatest challenge for XUL is to place itself in the mind of
consumers as a viable useful cross platform solution. It could
certainly boost it's profile with a plugin for IE and more network
based example apps. Otherwise it might go the way of gopher.
-----

I guess what we need then is a functioning GRE & XRE and some plugin
mechanism. What do you think?

Laurens Holst

unread,
Apr 8, 2004, 7:24:55 AM4/8/04
to
Daniel Glazman wrote:
> Remember IE is not the future of Microsoft. I think you can expect more
> and more Tasman-everywhere in a quite near future.
>
> a. Microsoft has built Tasman on more platforms that Mozilla (dixit
> MSFT themselves, and I tend to believe them...)
> b. Tasman is almost certainly the next-gen browser on mobile devices
> powered by MSFT
> c. Tasman is already used in digital TV projects, MSN for Mac
> d. Tasman is much more standards compliant than MSIE's engine

If this Tasman is the same as MSN for Mac, then it seems pretty good...

http://www.macedition.com/cb/resources/css3support_selectors.html

Ranks highly on there. Maybe it's a project Tantek is working on?


~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Bauduin Raphael

unread,
Apr 8, 2004, 7:25:52 AM4/8/04
to KaiRo - Robert Kaiser, bre...@meer.net
KaiRo - Robert Kaiser wrote:
> > build a new, unified desktop/web application platform
>
>> from pieces of Mozilla and GNOME code, starting now.
>
>
> I still think that it's a shame that Mozilla project is ignoring KDE
> (and the other way round). Konqueror/KHTML seem not to be reason enough
> for me to be that ignorant. This looks to me as it may lead to a massive
> split with some Linux distributors and a big community user, as many of
> them strongly support KDE.
> OTOH, we need to focus on working on something, and we can't let
> ourselves get split up into working on too many different things. And as
> GNOME people have no good web browser but Gecko-based products, it's the
> logical thing to do. If we really want an alliance of OSS projects to
> win, we should not ignore that half of the Linux desktops (or more) are
> not on GNOME but KDE, and we only can achieve good support of the OSS
> communities by integrating with that as well, IMO.
> We may not build everything with KDE in a "unified platform" - but we
> should be able integrate much, much more. We're losing market on Linux
> if we don't, I fear.
>
> Robert Kaiser

I never saw any explanation as to how this situation arose.... Have
there been contacts between developers of both projects? I don't want
flamewars, but I'd like to understand why there is so poor collaboration
between Mozilla and KDE and how it could be resolved. Is there hope this
situation could change?

I'm a user of Firefox/Thunderbird, and occasional developer of
extensions for them, but I definitively prefer the KDE desktop and its
technologies (dcop, kio, etc).
When someone mentioned a XUL oriented KDE project [1] on mozillazine, he
got the answer that "noooone cares about those projects". Isn't a XUL
project outside of mozilla a good thing?

I sadly enough don't have time to devote to a KDE integration of Mozilla
products (or vice-versa), but I would consider it great news if that
integration happened.
I would find it great if Firefox let me use control it via dcop. I would
also find it great if gecko could be used as rendring engine in
konqueror (was possible, but is unmaintained).
KDE's motto seems to be "the integrative desktop". Should be a good sign
for futur possible collaboration, no?


Raph


[1]: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/kaxul

Gerald Bauer

unread,
Apr 8, 2004, 7:44:58 AM4/8/04
to
> As far as Qt integration goes, there is no barrier to someone building
> gfx/qt, widget/qt, nsNativeThemeQt, and any other desirable Qt/KDE
> integration into Mozilla. No-one has volunteered to do it, and no
> companies seem interested in doing it. So it hasn't been done.

Allow me to highlight the KaXUL and uXUL project online @
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/kaxul

- Gerald

-------------------
Gerald Bauer
Open XUL Alliance - A Rich Internet For Everyone |
http://xul.sourceforge.net

Gerald Bauer

unread,
Apr 8, 2004, 8:03:16 AM4/8/04
to
> I feel we'd really need more tools.
> Or maybe just one too, the killer XUL GUI builder.

Allow me to suggest that if you open up and charter a forms designer
(UI designer) that supports many XML UI formats not just Mozilla XUL
than you will likely get much more buy-in. For example, if I dare to
say there are many XML UI language toolkits listed on the Open XUL
Alliance site @ http://xul.sourceforge.net that lack their own
designer and thus they might be interested in joining in.

Also note that many projects use Java and thus are a perfect fit for
uniting around an Eclipse code base. For what a single person can
achieve check out Theodore, for example, a forms designer for SwiXML
and Thinlet online @ http://www.carlsbadcubes.com/theodore

KaiRo - Robert Kaiser

unread,
Apr 8, 2004, 8:07:25 AM4/8/04
to
> I never saw any explanation as to how this situation arose.... Have
> there been contacts between developers of both projects? I don't want
> flamewars, but I'd like to understand why there is so poor collaboration
> between Mozilla and KDE and how it could be resolved. Is there hope this
> situation could change?

Well, contact never has been really started, AFAIK. The problem is that
KDE people didn't need a browser, as they intented Konqueror/KHTML
themselves, and so they didn't see a need in contact.
Mozilla/Netscape people had enough to do as the biggest user base is on
Win32 and integration there is/was much more interesting for lots of
people than on Linux desktops, which got not too much attantion (both
big desktops). As GNOME needed a browser and invented Gecko-embedding
browsers to do that, some contacts arose, and that's why we have more
contact here. Additionally, we have someone of RedHat who's
participating in Mozilla, but noone of the big KDE-preferring distros
(SuSE or others). And that's what did lead us here, from my perspective.

> I'm a user of Firefox/Thunderbird, and occasional developer of
> extensions for them, but I definitively prefer the KDE desktop and its
> technologies (dcop, kio, etc).

Me as well. And I'd love us to be able to use kio as well as gonomevfs,
for example...

Robert Kaiser

Gervase Markham

unread,
Apr 8, 2004, 8:08:15 AM4/8/04
to
Bauduin Raphael wrote:

> When someone mentioned a XUL oriented KDE project [1] on mozillazine, he
> got the answer that "noooone cares about those projects".

That was probably Gerald. Any reaction was probably a reaction to him
rather than a reaction to the project itself (which may be great; I
don't know.)

We'd even all start being happy about what Gerald is doing if he'd stop
appropriating our names and trademarks and diluting their meaning.

Gerv

KaiRo - Robert Kaiser

unread,
Apr 8, 2004, 8:28:17 AM4/8/04
to
> I made a third argument, that Windows to Linux migration is aided by
> making certain high-use apps cross-platform ("think Mozilla-the-suite,
> Firefox, Thunderbird, Open Office").

Hmm, I well remember that my decision to change my platform from Win to
Linux was made on the basis that "the main app I use is Mozilla, and it
works on both sides of the medal the same, using the same theme that I
designed" - and that made it really nice, and I'm happy I switched
today, and still loving that Seamonkey works very similar to older
Seamonkeys or even Netscape 4.x (which I used for E-Mail until I swapped
platforms).

> As GNOME improves its file picker and print dialogs, we are quite happy
> to use them and to dispense with our XUL alternatives, which we shipped
> (at least in the file picker case) because the native counterpart was so
> deficient. We have bugs on file and people working on using these new
> and improved native dialogs.

Hmm, I still like our file picker better than any of GNOME's (or KDE's,
BTW) that I have seen until now (including the GTK+ 2.0 file picker), as
ours is quite simple and compact as well as esay to use.

Well, supporting the OS facies might be at the cost of simplicity in
using sometimes, right. Well, sometimes we have to pay the price of
"progress" ;-)
(<rant>That reminds me that the time may come when I'll have to abandon
my loved Seamonkey as development might stop. Well, perhaps that's the
time when I'd have to consider to abandon Mozilla completely and switch
to Konqueror/KMail, competiton is open again then...</rant>)

Robert Kaiser

KaiRo - Robert Kaiser

unread,
Apr 8, 2004, 8:29:35 AM4/8/04
to
> As an example, consider the standard methods of configuring an
> application on each platform.
>
> MS Windows GNOME Mac OS X
> ---------------------------------------------------------------------
> Menu location "Tools" "Edit" <app name>
>
> Item title "Options..." "Preferences..." "Preferences..."
>
> ---------------------------------------------------------------------

This might get me a step nearer in discovering why I hate Firefox but
love Seamonkey, thanks for your help ;-)

Robert Kaiser

James Graham

unread,
Apr 8, 2004, 8:45:49 AM4/8/04
to
Matthew Thomas wrote:
> Brendan Eich wrote:
>
>>...
>>The long-term result would be not only a lack of cross-platform apps
>>-- there would be a lack of new cross-platform contents and protocols
>>needed to countervail XAML and other Longhorn formats, protocols, and
>>languages.
>
>
> Throughout this you seem to be assuming that any alternative to XAML
> needs to be cross-platform. But from what I have read, XAML is not
> cross-platform; it is intended to produce applications that will make
> sense on Microsoft Windows. Even if those applications can be run on
> other platforms, they will be ugly and inconsistent on those other platforms.
>
> In competing with XAML, it may be that you think cross-platform-ness is
> part of the solution. I hope you also consider that it may be part of
> the problem. Trying to work on multiple platforms may mean working
> poorly on all of them.

Platform consistency is certianly great from the point of view of making
apps easy to learn but it's not the whole story. Most users use non
standard, cross platform interfaces all the time - through 'web apps'
such as Amazon or hotmail. In general, these interfaces *really* suck,
but most people seem to use them OK.

Since many people would like better interfaces on these types of apps, I
would be surprised if people didn't start using technologies such as
XAML to produce more native-like applications that run over the net. At
the very least, I would expect people to use it in intranet situations
which will again encourage people to use IE at home and create the
perception that since IE has 9x% of the market, it's OK to use
IE-specific technologies over the net as a whole. Mozilla offers a
cross-platform alternative to this particular use of XAML which retains
the majority of the advantages that XAML has over HTML.

This is still relevant even if people actually use native browsers that
embed gecko. Last time I checked, it was still possible to use XUL in
epiphany, for example.

> In general, the more cross-platform a graphical application is, the less
> desktop/OS integration it will have. (Prominent examples include Mozilla
> 1.x on every platform, Java desktop apps on most platforms, and
> Microsoft Word 6.0 on the Mac.)
>
> This is far from a perfect correlation; it is easy to make applications
> that are equally horrible on multiple platforms! But it is very hard to
> make applications that are a joy to use on multiple platforms.

So why the opposition to *improving* the OS integration? It may never be
perfect but it might be good enough that the other advantages of being
cross-platform or the other advantages of XUL outweigh the issues with
interface consistency.

As an aside, I could mention that being a native app doesn't ensure
platform consistency either - both Apple and Microsoft violate their own
HIGs (if Microsoft even has a HIG document? - I remember not being able
to find one) on a regular basis. So it's not like users are used to a
consistent interface to the level that you specify.

> Perhaps you can see that if someone implemented a standards-compliant
> cross-platform configuration interface using XUL, it would be a minor
> miracle. It would not be something we could expect all, or even most,
> application developers to achieve.

There is nothing, in principle, to stop a developer shipping different
chrome for each platform they target. Having XUL flexible enough to
allow chrome to feel native when designed for a particuloar platform is
certianly an excellent goal. The fact that most application developers
don't do this suggests that, if they were not developing in a cross
platform framework, they would produce a single-platform application
instead. Having an application that doesn't quite blend in wth your
default desktop environment is often much better than having no
application at all.

Bauduin Raphael

unread,
Apr 8, 2004, 9:25:06 AM4/8/04
to

OK, let's forget this "generalisation" on the forum then.

If Robert and me are a representative sample of KDE+Mozilla users (not
sure at all :-), there's interest from users for better collaboration.
But even if we're not representative, better collaboration wouldn't
harm, and could open a lot of possibilities.

But is there interest from the mozilla developers to enable this?
How could I, as a non-Mozilla developer, help?

Raph

Boris Zbarsky

unread,
Apr 8, 2004, 9:15:35 AM4/8/04
to
Brendan Eich wrote:
> I. Build cross-platform apps from the ground up, using Gecko, native
> theme-based rendering, and good desktop/OS integration.

In this case we need to put a LOT of effort into native theme-based
rendering. I'm not sure how this works for XUL, but for native-themed
form controls we have this evil IsWidgetStyled hack....

> The time frame for this plan is now, with working code by 2nd half of
> this year.

Um... That's a lot of code to get working. Do we have anyone who has
time to work on this before then?

-Boris

Ben Bucksch

unread,
Apr 8, 2004, 11:14:21 AM4/8/04
to
Gervase Markham wrote:

> Nigel McFarlane wrote:
>
>> A. Popularity is worth nothing.
>
> I don't agree. Popularity (in terms of use) is worth a bunch of
> webmasters taking notice

His point is that popularity *alone* is worth nothing. If you achieve
popularity by emulating Microsoft, then you could just as well not
exist. That's why my blood pressure increases everytime somebody argues
in a bug "but MSIE/Outlook does it like that, and if we don't, we'll
drive users away".

OTOH, a software that nobody uses or takes note of is just as useless.
So, as Nigel stated very well, popularity may well be a sub-goal. E.g.,
the top goal may be "Make people happy", and "promote open access to
information" and "achieve large user-base" may be sub-goals of that, but
the means to achieve that must not conflict with the higher-level goals.

That's one reason why I think that a *clear*, concrete mission statement
is important.


If it was *my* decision, I'd define mozilla.org's goal as roughly:
"Make the best browser engine, adhering strictly to open standards, but
still being backwards-compatible enough to be usable, secure and
user-friendly, but adhering to nettiquette. Do what's good for the
world, even if it means alienating some groups. Target group are
developers embedding the engine in their own browsers, but not end
users. mozilla.org itself only coordinates the work of contributors to
the Mozilla code."
This does intentionally leave out Mozilla as application platform, see
below. It also leaves out actual products (Seamonkey, Thunderbird etc.),
I'd maybe make external projects out of them.

>> C. No one needs another complex OO framework
>>
>> We have Java. We have Mono. We have C++. Any attempt
>> to make Mozilla another complex OO framework suitable for
>> high-level programmers is a waste of time.
>
> I think that several companies building on the Mozilla platform would
> disagree with you.

Not sure if you count me in that, but I agree with Nigel here.

IMHO, Mozilla should concentrate on what it does best: building a
browser engine. There is arguably no better HTML/CSS renderer than Gecko
(in terms of standard compliance plus backwards-compatibility), and
hardly any choice at all if you want to use Open Source. OTOH, there are
IMHO a ton of better application platforms and tools (even enough if you
count in the criteria for cross-platform, XML-based etc.).

Mike Shaver

unread,
Apr 8, 2004, 10:26:22 AM4/8/04
to
Matthew Thomas wrote:
> None of the differences I have listed can be fixed using themes. A few
> can be fixed using sufficiently complicated overlays. But surely at some
> point even that becomes more difficult than just designing for one
> platform at a time.

I don't agree with your "surely" conclusion, at least not solely on the
basis of what's been presented in the rest of your message, but even a
cross-platform toolkit doesn't mean that you have to use the same UI
markup on all platforms. It means that you _can_, where it makes sense,
and it means that skills and tools and components are more portable
between platforms. If you need different XUL2 filepicker widgets for
GNOME/OS X/XP/Longhorn/BeOS, you can do that, but you don't have to
learn an entirely new API or even markup vocabulary to do so. And you
also don't have to duplicate the toolbar or tree-display widgetry in
different native FE APIs, which is the pain that many of us have
suffered through on pre-Mozilla Netscape products as well as in other
software endeavours. We would have _killed_ for the ability to get
basic functionality on all platforms, no matter how marginal, and then
polish or tweak or even replace-wholesale different components to make
them fit the platform better. I think I actually tried to kill someone
about that, and I wasn't really working on the FE very much at all.

A cross-platform toolkit will, IMO, let "platform specialists" spend
more time polishing and integrating, and less time keeping up with
changes in basic window layout, etc. I think we will end up with
_better_ platform integration capabilities by continuing to improve the
cross-platform toolkit substrate, in the medium-term and beyond.

Mike

Ben Bucksch

unread,
Apr 8, 2004, 11:16:35 AM4/8/04
to
Ben Bucksch wrote:

> Do what's good for the world, even if it means alienating some groups.

Sorry, that was badly worded. I didn't mean to ignore e.g. blind people
to cater for the majority, but exactly the opposite.

Matthew Thomas

unread,
Apr 8, 2004, 11:55:51 AM4/8/04
to
Brendan Eich wrote:
>
> Matthew Thomas wrote:
> >
> > Throughout this you seem to be assuming that any alternative to XAML
> > needs to be cross-platform.
>
> No, I *argued* that cross-platform is the best way to keep open
> standards both interoperable and relevant,

That's what I was expecting you to argue. But you went straight into "a


lack of cross-platform apps -- there would be a lack of new
cross-platform contents and protocols needed to countervail XAML and

other Longhorn formats". No explanation, then or later, of why
cross-platform-ness was necessary or even desirable for that countervailing.

> because user-agent market
> share matters,

Yes, but that's Boris's (1-3). We're talking about (5-6) -- the formats,
the protocols, and the platform for developing other applications with
those formats and protocols.

> and because standards are under attack by
> single-platform purveyors.

Purveyors? Microsoft is the only such attacker you talked about. Apple,
Red Hat, SuSE, and so on are also single-platform purveyors, but they're
not attacking standards, are they? If Microsoft is your only example,
picking out Microsoft's single-platform-ness to demonstrate the
importance of cross-platform-ness doesn't stand up. You might as well
say that standards are under attack by organizations with names starting
with M. (Quick, time for another Mozilla name-change!)

> I made a second argument, that Linux market share is poised to rise
> more than other non-Windows platforms, and that Mozilla has the best
> chance of gaining the most distribution by riding that tide (but that
> we are also at risk of losing distribution deals in the short run by
> not having sufficiently native-looking UI).

Agreed, but that's also (1-3), not (5-6).

> I made a third argument, that Windows to Linux migration is aided by
> making certain high-use apps cross-platform ("think Mozilla-the-suite,
> Firefox, Thunderbird, Open Office").

Yup, but that's still (1-3), not (5-6).

> Please pay attention.

You're better than that.

>...


> I'd like to point out that the top ten killer apps on Windows, the
> ones that make it a compelling platform more than any HIG or UI
> consistency ever could, are a mess as far as UI consistency goes. Mom
> and Pop, and the Photoshop and Dreamweaver users, do not care enough
> to shun the low-cost hardware platform.
>
> Notice that Linux targets that same commodity hardware.
>
> Perhaps Linux should be a bit more consistent and shiny than Windows,
> but any argument of the form: "to beat Windows, first make a uniform,
> uber-consistent UI across all apps and the desktop" is false on its
> face.

Yet Mom and Pop, and the Photoshop and Dreamweaver users, aren't
switching to the low-cost/no-cost Linux and Gimp and Mozilla Composer.
Instead they're shelling out on new computers beefy enough to run
Windows XP, then shelling out more on Photoshop CS and Dreamweaver MX
2004. Could that be anything to do with the relative usability of
Windows and Linux, Photoshop and Gimp, Dreamweaver and Composer? Even slightly?

> What Linux needs first, and most, are killer apps (and things
> like a HAL, which Project Utopia may deliver -- but I digress).

A Web browser (such as Firefox) is not a killer app for Linux, because
Windows already has several Web browsers of similar price and usability
(such as, oh, Firefox). More relevant to this discussion, a
cross-platform Mozilla-based development environment wouldn't help in
producing killer apps for Linux, because those apps would very easily
work on Windows too.

A killer app for Linux would be something that *isn't available* on
Windows, or is much more expensive on Windows, or is much less usable on Windows.

"Mozilla-the-suite, Firefox, Thunderbird, [and] Open Office" are good
not because they're killer apps, but because (as you said) they help in
"app-before-kernel migration" from Windows. But they already exist.
Unless you can talk about other app genres that are preventing such
migration, genres that would be much easier to develop using a
cross-platform Mozilla-based technology environment, then you are
encouraging the development of such an environment for little obvious benefit.

> > As an example, consider the standard methods of configuring an
> > application on each platform.
> >
> > MS Windows GNOME Mac OS X
> > -------------------------------------------------------------------

> [snip]
> > Buttons "OK", "Cancel" "Close" (none)
> >
> > Changes happen after "OK" instantly instantly
> >
> > -------------------------------------------------------------------

>...


> I think you really ought to catch up on Mozilla's OS-theme-based
> native look integration before surfacing after so long (almost two
> years in this newsgroup) and raising issues already being fixed, if
> not already fixed.

The only thing Firefox 0.8 for Mac gets right is the position and name
of the menu item. I'll take your word for it that the GNOME version is
further ahead, though I would be surprised if it properly applied
changes instantly while the Mac version (which also should) does not.

> Also, it seems to me the table you made does not represent the
> platform state of the art accurately: e.g., GNOME uses Cancel and OK
> or another Affirmation label, in that order, nowadays; see
> http://developer.gnome.org/projects/gup/hig/1.0/windows.html#dialog-layout.

The section you linked to doesn't mention buttons at all, let alone
buttons in preferences windows. The section you want is <http://developer.gnome.org/projects/gup/hig/1.0/windows.html#preference-windows>:
|
| Buttons: Place a Close button in the lower right corner.
|
See? No "Cancel", no "OK". You can also see the recommended layout in
the native GNOME browsers Epiphany
<http://gnome.org/projects/epiphany/images/1.2-preferences-fonts.png>
and Galeon <http://galeon.sourceforge.net/graphics/shots/prefs.png>.

>...


> Please try to accept that we are, by executive decision and general
> consensus, committed to XP UI for the Mozilla platform.

>...

I know that (no need for "try to accept" whimpering). Seamonkey and
Firefox developers have invested some five years in techniques to make
Mozilla's UI more integrated on various platforms. The point is that
some of these techniques are generalizable to a "technology platform"
for easy use by new applications. But some (like different terminology,
instant-apply, control alignment, choice of controls, etc) aren't, and
will need to be reimplemented for each application.

That, combined with the lack of explanation of why cross-platform-ness
is necessary to compete against XAML etc, combined with growth in Linux
being Mozilla's biggest medium-term opportunity for market share, is why
I am questioning the opportunity cost (there's another Dismal Science
term for you) of spending time on a cross-platform technology
development platform whatsit.

If growth in Linux is Mozilla's greatest medium-term opportunity for
market share, and "What Linux needs first, and most, are killer apps",
it would make more sense to produce a development platform for making
Linux-only apps (candidates for killer-app status) easier to develop
than cross-platform apps. (Like Apple have tried to do for OS X, with
Cocoa, Project Builder, and XCode.)

> If you don't like this decision, wait a few years and maybe it will
> become clear that you were right.

>...

I doubt it. People still argue about whether Netscape failed more
because of the quality of the browser or more because of Microsoft. I
see no reason for people arguing about Mozilla to be any more sure of
themselves. :-)

Axel Hecht

unread,
Apr 8, 2004, 11:41:10 AM4/8/04
to
Bauduin Raphael wrote:

Interest, sure. I bet we essentially just lack manpower and skillz.
Maybe you should have beaten me and some KDE folks with a stick in
february. Though you and your sticks were busy enough.

I'd think that some of the work could be factorized by learning how
Gnome and KDE align in terms of desktop integration. As I think they are
to some extent. So we may be able to get desktop integration without
necessarily doing toolkit integration. Not the ideal world but better
than nothing.

Axel

Mike Shaver

unread,
Apr 8, 2004, 10:38:49 AM4/8/04
to
Ben Bucksch wrote:
> OTOH, there are
> IMHO a ton of better application platforms and tools (even enough if you
> count in the criteria for cross-platform, XML-based etc.).

I'm curious to know what platforms and tools you include in that "ton".
(I would include "open source" in the criteria, and probably "not
GPL-only" as well, because toolkits that are GPL-only or non-open-source
aren't viable for a lot of people.)

I'm having trouble thinking of any that are as mature as the Mozilla
platform, but maybe I'm just not sufficiently well-informed.

Mike

Brendan Eich

unread,
Apr 8, 2004, 12:09:56 PM4/8/04
to Daniel Glazman
Daniel Glazman wrote:

> There is one thing I learned about Microsoft: they can surprise us.
> And on this particular subject, they have a lot of cards in hand...

You may be right. MS could do almost anything, with the cash and staff
they have.

But my main point stands: old IE will be with us for many years, in
enough market share that web content authors will have to cope with it.

/be

Bauduin Raphael

unread,
Apr 8, 2004, 12:21:28 PM4/8/04
to
Axel Hecht wrote:
> Bauduin Raphael wrote:
>
>> Gervase Markham wrote:
>>
>>> Bauduin Raphael wrote:
>>>
>>>> When someone mentioned a XUL oriented KDE project [1] on
>>>> mozillazine, he got the answer that "noooone cares about those
>>>> projects".
>>>
>>>
>>>
>>>
>>> That was probably Gerald. Any reaction was probably a reaction to him
>>> rather than a reaction to the project itself (which may be great; I
>>> don't know.)
>>>
>>> We'd even all start being happy about what Gerald is doing if he'd
>>> stop appropriating our names and trademarks and diluting their meaning.
>>>
>>> Gerv
>>
>>
>>
>> OK, let's forget this "generalisation" on the forum then.
>>
>> If Robert and me are a representative sample of KDE+Mozilla users (not
>> sure at all :-), there's interest from users for better collaboration.
>> But even if we're not representative, better collaboration wouldn't
>> harm, and could open a lot of possibilities.
>>
>> But is there interest from the mozilla developers to enable this?
>> How could I, as a non-Mozilla developer, help?
>
>
> Interest, sure. I bet we essentially just lack manpower and skillz.
> Maybe you should have beaten me and some KDE folks with a stick in
> february. Though you and your sticks were busy enough.
>

I'll remember that for next time if it applies.

> I'd think that some of the work could be factorized by learning how
> Gnome and KDE align in terms of desktop integration. As I think they are
> to some extent. So we may be able to get desktop integration without
> necessarily doing toolkit integration. Not the ideal world but better
> than nothing.

Freedesktop.org seems the place where such alignment could happen for
both desktops.
An example of such a fdo development is dbus, though I don't know what
is the commitment of both desktops regarding this technology.

What makes it even harder is keeping Mozilla cross-platform.... (which
is really important I think). It would be sad though to have Mozilla
cross platform but work only with gnome technology.

Btw, OpenOffice has a project to integrate it in KDE
(http://kde.openoffice.org/). Maybe the way that is achieved could help
here as it doesn't diminish the gnome support. I never looked at it
deeply though....

Raph

>
> Axel

Brendan Eich

unread,
Apr 8, 2004, 12:19:42 PM4/8/04
to Boris Zbarsky
Boris Zbarsky wrote:
> Brendan Eich wrote:
>
>> I. Build cross-platform apps from the ground up, using Gecko, native
>> theme-based rendering, and good desktop/OS integration.
>
>
> In this case we need to put a LOT of effort into native theme-based
> rendering. I'm not sure how this works for XUL, but for native-themed
> form controls we have this evil IsWidgetStyled hack....


This is more a XUL issue than an HTML widget one, but XUL uses HTML
widgets for texts and textareas. What can I say? Evil hacks need to be
exorcised. Can you file a bug, or help me file one?


>> The time frame for this plan is now, with working code by 2nd half of
>> this year.
>
>
> Um... That's a lot of code to get working. Do we have anyone who has
> time to work on this before then?


Yes. And with some progress on the alliance front, we'll have more
hackers coming on board.

/be

Brendan Eich

unread,
Apr 8, 2004, 12:12:52 PM4/8/04
to KaiRo - Robert Kaiser
KaiRo - Robert Kaiser wrote:


There's a rough plan afoot to make a GNOME system theme for Firefox that
rearranges the menus, so that the Tools/Options you hate so much becomes
Edit/Preferences. Would that turn you around on Firefox? If so, I can
only say that it's the little things that matter.

/be

Brendan Eich

unread,
Apr 8, 2004, 12:23:26 PM4/8/04
to Ben Bucksch
Ben Bucksch wrote:
>
> If it was *my* decision, I'd define mozilla.org's goal as roughly:
> "Make the best browser engine, adhering strictly to open standards, but
> still being backwards-compatible enough to be usable, secure and
> user-friendly, but adhering to nettiquette. Do what's good for the
> world, even if it means alienating some groups. Target group are
> developers embedding the engine in their own browsers, but not end
> users. mozilla.org itself only coordinates the work of contributors to
> the Mozilla code."


We're not going to do this, because not only is it a recipe for failure
(as in no funding, no tinderboxes, lights go out) of the Mozilla
Foundation -- more important, it will (as I argued at length) likely
lead to warring platform XML cultures, and aid and abet the MS
hegemon-o-culture.

You seem to think the world is static, and the playing field is level.
Neither is the case on this planet.

/be

KaiRo - Robert Kaiser

unread,
Apr 8, 2004, 12:51:26 PM4/8/04
to

Actually, that was more of a joke of me - but there's something in it
that might hold some truth as well.

To really turn me around on Firefox, I would need the same abilites I
have in my current brower of choice (Seamonkey), e.g. when it comes down
to things like SVG, editing preferences, reaching of functionality, and
connection (not necessarily full integration) of my default mail client
(currently Seamonkey as well, probably better TB then). Over all that, I
have to be able to have this in nightlies that I compile from CVS and
not breaking too often because of new developments (so completely
external extensions always look dangerous to me). That's something that
only Seamonkey can provide me currently. And I don't expect that to
change soon, as I don't guess I'm in a primary target group of Firefox
(I'm a power user, web developer and Mozilla contributor, as you might
guess).
Being a bit too similar to IE (on the look-and-fell side) is a bit
alienating at first glance but I guess I'd accomodate. So there's some
truth about moving menu options but I recall Seamonkey having big
shiftings in menu structures in the past, and that never alienated me
enough for not liking it the way I do with Firefox now (I'm only
speaking from the perspective of me using it, I'm actually happy that
there is a growing user base of Firefox, as it help web standards and
the Mozilla project as a whole).

Robert Kaiser

KaiRo - Robert Kaiser

unread,
Apr 8, 2004, 12:54:24 PM4/8/04
to
>>> I. Build cross-platform apps from the ground up, using Gecko, native
>>> theme-based rendering, and good desktop/OS integration.
>>
>> In this case we need to put a LOT of effort into native theme-based
>> rendering. I'm not sure how this works for XUL, but for native-themed
>> form controls we have this evil IsWidgetStyled hack....
>
> This is more a XUL issue than an HTML widget one, but XUL uses HTML
> widgets for texts and textareas. What can I say? Evil hacks need to be
> exorcised. Can you file a bug, or help me file one?

Well, we really should move to XUL-based HTML controls (via XBL or
something like that - yes, I kow that they basically do exist but have
perf problems) some time anyways. Probably we should investigate what
makes that approach that hard to go (i.e. why do we lose perf using
XBL?) - man, I'd really love to have experience in serious hacking...

Robert Kaiser

Brendan Eich

unread,
Apr 8, 2004, 12:59:46 PM4/8/04
to KaiRo - Robert Kaiser
KaiRo - Robert Kaiser wrote:

> Well, we really should move to XUL-based HTML controls (via XBL or
> something like that - yes, I kow that they basically do exist but have
> perf problems) some time anyways.


That has nothing to do with what bz was talking about, AFAICT.


> Probably we should investigate what
> makes that approach that hard to go (i.e. why do we lose perf using
> XBL?) - man, I'd really love to have experience in serious hacking...


It's well-known what makes XBL form controls problematic -- it's
footprint (dynamic, they save static code footprint but require more
memory at runtime), not cycles. It's idle to speculate further, and
from what I can tell talking to bryner, and what I'm proposing we do
with GNOME folks, XBL form controls are irrelevant.

/be

James Graham

unread,
Apr 8, 2004, 1:09:17 PM4/8/04
to
Matthew Thomas wrote:
> Brendan Eich wrote:
>>Perhaps Linux should be a bit more consistent and shiny than Windows,
>>but any argument of the form: "to beat Windows, first make a uniform,
>>uber-consistent UI across all apps and the desktop" is false on its
>>face.
>
>
> Yet Mom and Pop, and the Photoshop and Dreamweaver users, aren't
> switching to the low-cost/no-cost Linux and Gimp and Mozilla Composer.
> Instead they're shelling out on new computers beefy enough to run
> Windows XP, then shelling out more on Photoshop CS and Dreamweaver MX
> 2004. Could that be anything to do with the relative usability of
> Windows and Linux, Photoshop and Gimp, Dreamweaver and Composer? Even slightly?

Ending that with 'even slightly?' makes that an irrelevant question. Of
course anything might be a 'slight' factor. A more interesting question
is, is it a big factor? Compared to the discrepancy between the feature
sets of Composer and Dreamweaver and Gimp and Photoshop and, under the
assumption that people use software for the tools it provides, any
effect due to the theoretical usability of the products (as opposed to
the much larger issue of familiarity with a particular product) is at
noise level.

The windows / linux question is slightly different (or, dependng on how
you want to look at it, the same but at a lower level) because people
have exsting software that will not run or will only run poorly on
Linux. They also have existing hardware that may be incompatible with
Linux. Those are very significant barriers to overcome. Even if there
emerges a Linux desktop system that is more user friendly than windows,
if those two problems aren't solved, people won't switch. This means
that creating great cross-platform apps could actually be *more*
significant to the mass adoption of Linux than creating killer
Linux-only apps.

Ben Bucksch

unread,
Apr 8, 2004, 1:19:42 PM4/8/04
to
Brendan Eich wrote:

> it will (as I argued at length) likely lead to warring platform XML
> cultures, and aid and abet the MS hegemon-o-culture.

I fully agree with you that the danger of Longhorn/.NET/XAML is there.
But I don't think it would be the job of mozilla.org to take on that
task. (Nor do I think that GNOME or even X is really up for it, but
that's another matter.)

Ben Bucksch

unread,
Apr 8, 2004, 1:17:46 PM4/8/04
to
Mike Shaver wrote:
I'm curious to know what platforms and tools you include in that "ton". (I would include "open source" in the criteria, and probably "not GPL-only" as well, because toolkits that are GPL-only or non-open-source aren't viable for a lot of people.)
Well, for many people, using Visual C++ or Delphi/Kylix or Cocoa is an acceptable tradeoff or even fun, but OK, taking your criteria, e.g.:
  • As for cross-platform toolkit, there is wxWindows (now wxWidgets), which is a wrapper around native toolkits, i.e. you have a single API, but really native look and behaviour on all platforms (modulo minor things like "Options" vs. "Preferences"), not emulation. wxWindows by far predates Mozilla (1992). If it would have been my decision, I would have used wxWindows or a workalike, i.e. a wrapper, for Mozilla from the beginning.
  • Qt (Trolltech/KDE) emulates native look on all major platforms. It's GPL for Open-Source people and proprietary (with support) for closed source people, which IMHO is a fair arrangement, despite my GPL dislike. Unfortunately, you need a proprietary license for non-Unix platforms, but the platforms are proprietary as well. It has a (mediocre) UI designer, can read the UI from XML, and has a somewhat nice API and I18N approach. Huge developer community (which has lots of advantages).
  • Similarily, GTK (GNOME) can read from XML (Glade), has a UI designer, can run emulated on Windows (and Mac?), is LGPL, and has a large community. Wrappers for many programming languages.
  • UIML offers a XML description of UIs, and that since 1997 (!). At least version 2 and above is quite abstract, has a notably nice approach for some things (you can even specify part of the UI behaviour *declaratively*). A bit underspecified, because it needs mappings ("vocabularies") to a concrete set of widgets. IIRC, there are mappings to e.g. .NET and Swing (using these means you depend on that toolkit), to wxWindows and others. There either is or could be a generic one (defining just "button", "listbox" etc.), deferring the concrete choice of toolkit until runtime. If I was to specify/implement an XML->widget mapping, I'd take a serious look at that.
  • Java's Swing is totally cross-platform. Limited to Java. Not sure about Open-Source implementations. Its UI sucks everywhere, at least used to, but maybe that improved with the Mac OS X implementation and the new GTK "look and feel" in 1.4.2.
  • SWT is a new toolkit made for Eclipse, but starting to be of general use. For Java. Like wxWindows, it's a unified API, but uses the actual native toolkits at runtime, so Java apps look like native apps.
  • There's an overwhelmingly huge FAQ about cross-platform GUIs. Unfortunately, it's quite old.
  • The GUI Toolkit, Framework Page has an interesting list of toolkits, inkl. Fresco/Interviews, XUL/XPFE :-), GNUStep, YAAF and V.
To be fair, some of these choices were not available when mozilla.org started SeaMonkey in 1998, but a some were. I'm sure I missed many as well. In any case, XUL was definitely not the first cross-platform or XML-based toolkit, as many people (not you) incorrectly say, and definitely is not the only one anymore.

Even if the above list may not have a perfect fit for a very specific need, I think that's plenty of choices, actually *too* many.

Brendan Eich

unread,
Apr 8, 2004, 1:44:50 PM4/8/04
to James Graham
James Graham wrote:
> Matthew Thomas wrote:
>
>> Brendan Eich wrote:
>>
>>> Perhaps Linux should be a bit more consistent and shiny than Windows,
>>> but any argument of the form: "to beat Windows, first make a uniform,
>>> uber-consistent UI across all apps and the desktop" is false on its
>>> face.
>>
>>
>> Yet Mom and Pop, and the Photoshop and Dreamweaver users, aren't
>> switching to the low-cost/no-cost Linux and Gimp and Mozilla Composer.
>> Instead they're shelling out on new computers beefy enough to run
>> Windows XP, then shelling out more on Photoshop CS and Dreamweaver MX
>> 2004. Could that be anything to do with the relative usability of
>> Windows and Linux, Photoshop and Gimp, Dreamweaver and Composer? Even
>> slightly?


(mpt, I'm surprised to see such fallacies from you.)


> Ending that with 'even slightly?' makes that an irrelevant question. Of
> course anything might be a 'slight' factor. A more interesting question
> is, is it a big factor? Compared to the discrepancy between the feature
> sets of Composer and Dreamweaver and Gimp and Photoshop and, under the
> assumption that people use software for the tools it provides, any
> effect due to the theoretical usability of the products (as opposed to
> the much larger issue of familiarity with a particular product) is at
> noise level.


Or below noise level, tempting people to skirt diminishing returns or
actually malinvest.

Fixing look&feel integration has high opportunity cost. It may well be
better to fix real bugs and add useful features, at least for market
champions such as Photoshop and Dreamweaver.

Adobe and Macromedia seem to think so, although they may also be
profitable enough to polish the look and feel -- as we all should hope
to be, and as we are doing with GNOME integration and GTK+ widget
rendering, at our own expense, in order to get better distribution.


> The windows / linux question is slightly different (or, dependng on how
> you want to look at it, the same but at a lower level) because people
> have exsting software that will not run or will only run poorly on
> Linux. They also have existing hardware that may be incompatible with
> Linux. Those are very significant barriers to overcome. Even if there
> emerges a Linux desktop system that is more user friendly than windows,
> if those two problems aren't solved, people won't switch. This means
> that creating great cross-platform apps could actually be *more*
> significant to the mass adoption of Linux than creating killer
> Linux-only apps.


Ding ding ding....

/be

fantasai

unread,
Apr 8, 2004, 1:42:24 PM4/8/04
to
Laurens Holst wrote:
>
> this Tasman is the same as MSN for Mac, then it seems pretty good...
>
> http://www.macedition.com/cb/resources/css3support_selectors.html
>
> Ranks highly on there. Maybe it's a project Tantek is working on?

Yep. http://tantek.com/projects/resume.html

~fantasai

--
http://fantasai.inkedblade.net/contact

Brendan Eich

unread,
Apr 8, 2004, 1:49:01 PM4/8/04
to Ben Bucksch


Well, do try to be helpful and not just clever: exactly who is up to the
task?

/be

Brendan Eich

unread,
Apr 8, 2004, 2:06:30 PM4/8/04
to Ben Bucksch
Ben Bucksch wrote:

> * As for cross-platform toolkit, there is wxWindows
> <http://www.wxwidgets.org> (now wxWidgets), which is a wrapper
> around native toolkits, i.e. you have a single API, but /really/


> native look and behaviour on all platforms (modulo minor things
> like "Options" vs. "Preferences"), not emulation.


Which means one gets the opposite trade-offs, the "road not taken"
costs: platform disparities, least common denominator widgets, and
different costs incurred filling in gaps. Did we really want to write a
tree widget for two out of three platforms in 1998, trying to match the
leading platform? Might it not have been better to write an XP tree widget?

It's mindless to point at the road not taken and claim that it was
obviously the right road to take. Nothing is that obvious. A "ton" of
bogus or late examples in your message to the contrary notwithstanding.

> wxWindows by
> /far/ predates Mozilla (1992). If it would have been my decision,


> I would have used wxWindows or a workalike, i.e. a wrapper, for
> Mozilla from the beginning.


We actually considered it in 1998. Or some of us did, myself included.
But there was a strong movement in favor of "using Raptor" (as Gecko
was then called) to do everything. Also, there was precedent people
wanted to carry forward from Netscape 4.5 for data-binding RDF to tree
widgets, and nothing like such data-binding widget support was in
wxWindows then.


> * Qt <http://www.trolltech.com/products/qt/> (Trolltech/KDE)


> emulates native look on all major platforms. It's GPL for
> Open-Source people and proprietary (with support) for closed
> source people, which IMHO is a fair arrangement,


Your HO notwithstanding, it's not usable in Mozilla code we host because
of this licensing incompatibility, and it ain't OSS-pure open source or
free software.

*Next*.


> * Similarily, GTK <http://www.gtk.org> (GNOME) can read from XML


> (Glade), has a UI designer, can run emulated on Windows (and
> Mac?), is LGPL, and has a large community. Wrappers for many
> programming languages.


Ben, stop listing things everyone knows about. We switched from Motif
to GTK+ in October 1998, but there's no way we could have used it on
Windows (or Mac, if you have to put a ? in a parenthetical, you are
trying to make an absurdly weak claim).

I think arguing is fun and all, but your "shoulda coulda woulda" mode of
gainsaying what Mozilla has done is fruitless.


> * UIML <http://www.uiml.org> offers a XML description of UIs, and
> that since 1997 (!).


So what? Why does precedent matter? Must everything be reused,
conserved? Obviously not, as people keep reinventing XUL. Possibly
some of them even have good reasons.


[snip]


>
> To be fair, some of these choices were not available when mozilla.org
> started SeaMonkey in 1998, but a some were.


Most were not. Your word choice is not completely honest here.


> I'm sure I missed many as
> well. In any case, XUL was definitely not the first cross-platform or
> XML-based toolkit, as many people (not you) incorrectly say, and
> definitely is not the only one anymore.


Yeah, everyone knows this. Why belabor it?

Although it makes my point that NIH is a universal part of human nature,
and also that sometimes it may be better not to try to reuse a
pig-in-a-poke, or even a sturdy last-year's-model that's out of gas. It
may actually be better to do something new, even if it learns from past
efforts, or just happens to look like them from a distance.


> Even if the above list may not have a perfect fit for a very specific
> need, I think that's plenty of choices, actually *too* many.


Now that's a good point. Too many choices is a strong motivation for
DIY, which is not always NIH. (DIY == Do It Yourself; NIH == Not
Invented Here). One reason is that all those alternatives take too long
to evaluate; another is that they can't all possibly be good, or good
for particular requirements we faced in 1998.

Particulars matter; abstraction and generality can be pitfalls. XUL fit
certain specific requirements for Mozilla, and of course for the company
paying most of the developers in the early days, Netscape. It's to the
credit of the many people who did the work that XUL, XPCOM, etc., turned
out to be general enough for lots of applications.

/be

Ben Bucksch

unread,
Apr 8, 2004, 2:02:43 PM4/8/04
to
Brendan Eich wrote:

> Well, do try to be helpful and not just clever: exactly who is up to
> the task?

I think that the Fresco (formerly Berlin, formerlly Interviews) has the
best GUI foundation I know (replacement for X and toolkits). Designed 10
years ago by co-authors of the famous Design Patterns book (and many
examples from the book are actually straight from Interviews/Fresco),
and a testing ground for CORBA, it was well beyond its time, and is
*still* more advanced than Longhorn or even Mac OS X/NextSTEP. (X
extensions look like a terrible patchwork in comparison to that.) The
project terribly lacks talented developers (mainly programm designers).

I'd use a general IPC mechanism with OO. Maybe CORBA, maybe something
completely new, where I can also inherit from remote objects. Make apps
heavily use that (roughly like in KDE, maybe even more so, but
standardized APIs), finally getting rid of monolithic apps.

We already have many managed languages: Java, Python, Ruby, Perl. C++
with stdlib. Use them together with the IPC mechanism.

If you want to specify the UI in XML, use UIML.

I'm trying to play with UIs as well, but extremely experimental and in
early stage: <http://www.bucksch.com/1/projects/ooui/>.

My personal hope is my own project succeeds (both technically and
socially) or that Fresco starts to fly or both. If not, UIML looks
decent (although I didn't have time to read the spec yet). If all
breaks, KDE is closer to what I imagine than GNOME (OO, components in
action).

Daniel Glazman

unread,
Apr 8, 2004, 2:42:08 PM4/8/04
to
Brendan Eich wrote:

>> There is one thing I learned about Microsoft: they can surprise us.
>> And on this particular subject, they have a lot of cards in hand...
>
> You may be right. MS could do almost anything, with the cash and staff
> they have.

My point exactly. Remember how they started the IE team? 1 person at the
beginning of the 1st month, 8 a week later, 80 at the end of the month.
And they have Tasman. They still have Chris Wilson, Tantek Çelik, Jean
Paoli and a few others.

> But my main point stands: old IE will be with us for many years, in
> enough market share that web content authors will have to cope with it.

Well, for the time being, all indicators lead to a similar forecast.
But we should not underestimate MSFT's ability to break the model
and have a very successful revamped MSN in a year and a half from now.
When I mean very successful, I mean with a market share greater than
legacy MSIE's. It seems to me that it's exactly what they are trying to
do.

And it's another reason why we should not focus only on the browser...

</Daniel>

A.M. Kuchling

unread,
Apr 8, 2004, 2:50:31 PM4/8/04
to
On Thu, 08 Apr 2004 11:06:30 -0700,
Brendan Eich <bre...@meer.net> wrote:
> It's mindless to point at the road not taken and claim that it was
> obviously the right road to take. Nothing is that obvious. A "ton" of
> bogus or late examples in your message to the contrary notwithstanding.

Bucksch's point was not, I think, that Mozilla should have used wxWidgets
back in 1998, but that these systems are Mozilla's competition now, and if
people ask "Why should I write an application in Mozilla+XUL and not in
Python+GTk, Python+Qt, Perl+Tk, etc.?", there needs to be some good answer.
If no such answer exists, then promotion of Mozilla for application
development is not likely to be successful.

So, think about it: why *should* people write applications in XUL and not
using a language and GUI toolkit of their choice?

--amk


Brendan Eich

unread,
Apr 8, 2004, 2:50:58 PM4/8/04
to Ben Bucksch
Ben Bucksch wrote:
> Brendan Eich wrote:
>
>> Well, do try to be helpful and not just clever: exactly who is up to
>> the task?


You then go on to talk subjectively about *what*, not *who*. I meant
GNOME as in the developers and leaders, as much as the code. You seem
to have meant by "GNOME is not up for it" that the code or architecture
wasn't good enough.

Sorry if I misread you, but my reading matters more, because as you go
on to say, the projects you favor are old and unsupported.

Yes, of course: code and architecture quality matter too. So let's get
down to brass tacks.


> I think that the Fresco (formerly Berlin, formerlly Interviews) has the
> best GUI foundation I know (replacement for X and toolkits). Designed 10
> years ago by co-authors of the famous Design Patterns book (and many
> examples from the book are actually straight from Interviews/Fresco),
> and a testing ground for CORBA, it was well beyond its time, and is
> *still* more advanced than Longhorn or even Mac OS X/NextSTEP. (X
> extensions look like a terrible patchwork in comparison to that.) The
> project terribly lacks talented developers (mainly programm designers).


Exactly what is wrong with GTK+ compared to Interviews (which I know
something about; I was at SGI from 1985 to 1992, and Mark Linton was
there in the later days)?

Please list three concrete and relevant use-cases or problems where
InterViews beats GTK+; give example code. Lack of intergalactic object
oriented buzzword compliance is not admissible.


> I'd use a general IPC mechanism with OO. Maybe CORBA, maybe something
> completely new, where I can also inherit from remote objects. Make apps
> heavily use that (roughly like in KDE, maybe even more so, but
> standardized APIs), finally getting rid of monolithic apps.


GNOME already went down the CORBA route. Painful lessons were learned:
about the incomplete and buggy spec, lack of good implementations, and
pitfalls overusing remoting.

See http://www.sgi.com/grafica/future/futnotes.html for a humorous
reaction to the various object-oriented piles of bovine stuff (not
including InterViews) that got SGI in big trouble in the early nineties
(http://www.molgen.mpg.de/~wwwutz/Unix_Haters/usability.html). Let's
learn from the past and not repeat those mistakes.


> We already have many managed languages: Java, Python, Ruby, Perl. C++
> with stdlib. Use them together with the IPC mechanism.


You aren't using "managed" in the sense others do. C++ is *not* a
managed language, with or without stdlib. Perl and Python lack a
sandbox security model, although one could be added at some cost.

Another big problem with this ad-hoc N-way programming language
integration plan: each implementation is its own runtime, with its own
ref-counted or GC'd object heap. Integration requires O(N) work on the
bridges to a common model, such as XPCOM; if not O(N^2) work bridging
each language to every other.

Bridging also requires solving a variant of the distributed GC problem,
where uncollectable cycles among the heaps can pile up big memory leaks.
See http://www-2.cs.cmu.edu/~roc/HetGC.html.

Then there are "impedence mismatches" between the runtimes' APIs and
object systems.


> If you want to specify the UI in XML, use UIML.


Build XUL-scale apps with it, then we'll talk.


> I'm trying to play with UIs as well, but extremely experimental and in
> early stage: <http://www.bucksch.com/1/projects/ooui/>.
>
> My personal hope is my own project succeeds (both technically and
> socially) or that Fresco starts to fly or both. If not, UIML looks
> decent (although I didn't have time to read the spec yet). If all
> breaks, KDE is closer to what I imagine than GNOME (OO, components in
> action).


Good luck with that. It doesn't sound like you have more than your own
initiative involved here. What's the point? Wouldn't jumping on the
KDE bandwagon and beefing it up with XML UI, hardware accelerated
graphics, and truly managed language runtimes be better?

I do not propose that because we are, for want of volunteers, much
farther form KDE than from GNOME, and Mozilla + GNOME + Mono has a
better shot in my judgment. Don't dare say I'm against KDE -- but call
me a realist.

/be

Christopher Blizzard

unread,
Apr 8, 2004, 2:50:05 PM4/8/04
to
Bauduin Raphael wrote:

>
> I never saw any explanation as to how this situation arose.... Have
> there been contacts between developers of both projects? I don't want
> flamewars, but I'd like to understand why there is so poor
> collaboration between Mozilla and KDE and how it could be resolved. Is
> there hope this situation could change?

It's pretty simple. KDE wrote their own web browser. I don't imagine
they would be willing to ditch it for Mozilla at this point if for no
other reason than pride and the emotional investment. Do you?

--Chris

--
------------
Christopher Blizzard
http://www.mozilla.org
------------

Ben Bucksch

unread,
Apr 8, 2004, 2:41:46 PM4/8/04
to
Brendan Eich wrote:

> Ben Bucksch wrote:
>
>> wxWindows
>
> platform disparities

... are *wanted* - if I run Mac OS X, I *want* my apps to look like Mac
apps. If I run Unix, I know my favourite toolkit by heart (incl. all the
ideosyncracies) and are annoyed, if the shortcut doesn't work.

> least common denominator widgets

not true. wxWindows implements those widgets which are missing itself,
e.g. a tree. The tree widget probably wouldn't have been up for the task
of Mailnews' threadpane, but you could have implemented that, just like
you implemented the XUL version.

> Did we really want to write a tree widget for two out of three

> platforms in 1998 ... Might it not have been better to write an XP
> tree widget?

Well, you implemented it anyways. You can use the native one on one
platform and your own one the other 2. Even if you use your own tree
widget for all 3 platforms, we'd still have the advantages for all the
other widgets.

> It's mindless to point at the road not taken and claim that it was
> obviously the right road to take. Nothing is that obvious.

Do you think now that it might have been the right road? Before starting
to put the full power behind XUL *now* (I think it would still be
*enormous* effort to make XUL a good-quality toolkit for general use),
and given that we have Camino and Galeon, could it be time to reconsider?

> Your HO notwithstanding, it's not usable in Mozilla code we host
> because of this licensing incompatibility, and it ain't OSS-pure open
> source or free software.

Did you talk with Trolltech about that? They catered to KDE (which was a
good business move), maybe they would have made a ($) deal with
Netscape, I don't know.

> Ben, stop listing things everyone knows about.

Well, the question was which toolkits exist today and if it makes sense
to add another one.

You propose to add a new, general-purpose toolkit to the world. My
response was 'there are tons already, no need for yet another one'.
Shaver asked which ones, and that's a list. Surely, GTK and Qt would
should be listed as toolkits in competition with XUL, esp. since both
are cross-platform and even offer a XML representation?

>> * UIML <http://www.uiml.org> offers a XML description of UIs, and
>> that since 1997 (!).
>
> So what? Why does precedent matter? Must everything be reused,
> conserved?

No. But I happen to think that UIML has a much better API than XUL, from
what I could see on a brief look. It was and is in any case a choice
available, and that was the subject.

>> I'm sure I missed many as well. In any case, XUL was definitely not
>> the first cross-platform or XML-based toolkit, as many people (not
>> you) incorrectly say, and definitely is not the only one anymore.
>
> Yeah, everyone knows this.

Obviously not, because I've read many times in XUL advocacy that it's
the first cross-platform and/or XML-bases toolkit.

> Although it makes my point that NIH is a universal part of human
> nature, and also that sometimes it may be better not to try to reuse a
> pig-in-a-poke, or even a sturdy last-year's-model that's out of gas.
> It may actually be better to do something new, even if it learns from
> past efforts, or just happens to look like them from a distance.

Agreed. Sometimes. Usually not. If I look at the string library and the
many costy API changes, I think Mozilla is a prime example of NIH.

>> I think that's plenty of choices, actually *too* many.
>
> Now that's a good point. Too many choices is a strong motivation for

> ... Do It Yourself ... One reason is that all those alternatives take

> too long to evaluate; another is that they can't all possibly be good

*Exactly* (The latter also known as fragmentation.)

IMHO the worst is that I have to learn 5 similar, yet different APIs, if
I want to scatch my itches across the apps I use. Plus the well-known
usability problems.

> Particulars matter; abstraction and generality can be pitfalls.

Well, believe it or not, I am a Mozilla developer as well ;-). I
wouldn't be writing that, if I wasn't fairly convinced that this was a
bad choice, based on my own experimence, situation and observation of
others. I won't go over that again, because we had these discussions 3
years ago, and they weren't very enjoyable. I just wanted to state that
I don't think putting even *more* throttle behind XUL is a good idea,
both for mozilla.org and the Open-Source community at large.

> It's to the credit of the many people who did the work that XUL,
> XPCOM, etc., turned out to be general enough for lots of applications.

Yes. I find KaXul (mentioned earlier in the thread) to be good evidence.

But you can't ignore that the people at mozdev are facing *major* pain
when developing XUL-based apps (bugs, lack of documentation, constant
API changes). So do I. Windows apps run for years (a decade?) without
recompilation, while XUL extensions usually break within months, for a
start. I don't think we're even half way towards a good toolkit.

In any case, I personally think that the most important outcode of
mozilla.org is the browser engine. That's what people think of when they
think "Mozilla". I think mozilla.org should just stick to that. But I'm
not the project leader (and never will be ;-P ).

Ben

Brendan Eich

unread,
Apr 8, 2004, 2:56:58 PM4/8/04
to Ben Bucksch
Ben Bucksch wrote:
> Brendan Eich wrote:
>
>> Ben Bucksch wrote:
>>
>>> wxWindows
>>
>> platform disparities
>
> ... are *wanted* - if I run Mac OS X, I *want* my apps to look like Mac
> apps. If I run Unix, I know my favourite toolkit by heart (incl. all the
> ideosyncracies) and are annoyed, if the shortcut doesn't work.


Not what I meant: do you want your Mac OS X app to lack a good sheets
dialog because Windows and Unix don't have any such thing? Do you want
it to lack coherent alpha-blending?


>> least common denominator widgets
>
> not true. wxWindows implements those widgets which are missing itself,
> e.g. a tree. The tree widget probably wouldn't have been up for the task
> of Mailnews' threadpane, but you could have implemented that, just like
> you implemented the XUL version.


You're right, we could have.

Notice that I was among those evaluating wxWindows, briefly, in 1998.
You may be right that we should have built on it, but for the reasons I
gave, some of which were Netscape-oriented, but most of which were
Raptor-rah-rah and NIH, we did not. That may have been a mistake.

But it's fruitless to ponder. You can't construct strong proofs,
especially because human action and large-scale software are so complex
that we don't know all the costs of the road not taken.

And anyway, it's all water way under the bridge.

The rest of your examples still strike me as mildly to totally bogus,
but I wanted to give the full story, such as it was, of Mozilla and
wxWindows.

/be

It is loading more messages.
0 new messages