2003-06-09 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: mitchell, blizzard, myk, gerv, seth, asa, scott, dmose, scc.
*1.4*
- Down to 5 or 6 blockers
- rc2 when a sufficient number are wrapped up
- Potential for rebranding as final
- Release in the next day or two
- We should stop taking changes post-rc2 for a number of days while we
evaluate
*1.4 Branch drivers*
- Representatives of some companies shipping from it
- Other drivers might pitch in
- Asa or brendan also
- Separate heading on drivers list web page
- Same mail alias
*1.5*
- Asa is putting together a (pretty darn short) blockers list for
Mozilla Firebird being the premier app
- A couple of features on it, though - HTML sidebar, XPUninstall (hyatt)
- Need to hook up DOM Inspector, site nav, Venkman, style switching into
a 'default build'
- It will be minimalist at first start - lightweight browsing experience
- But also selectively enable advanced features
- Realistic timeframe for 1.5 alpha? Asa - stick to current schedule
- When do we stop shipping Seamonkey? Still open question
*Mozilla Firebird/Thunderbird releases*
- Might be good to do a Thunderbird 0.1 soon
- Need to get the testing coverage
- Better integration between the two needed? OK on Windows, probably;
problems on Mac and Linux
Gerv
Peter Lairo
> 2003-06-09 - Summary of mozilla.org staff meeting
> -------------------------------------------------
>
> *1.5*
> - When do we stop shipping Seamonkey?
When there is (near) *feature parity* between Mozilla Suite and FB/TB ?
> *Mozilla Firebird/Thunderbird releases*
> - Better integration between the two needed?
Definetely!
We need (as a minimum):
1. "Send Link" in FB should use TB (prolly handled by OS? If not, a
pref!). Therefore, also:
2. Shared Addressbook
3. TB: middle-click opens in new tab (this is a biggie).
4. Digital Certificates (e.g., Thawte: https://www.thawte.com/home.html)
OTHER NEEDED FIXES (not related to "integration"):
5. Ability to "Close All Tabs" by default (not an extension). Also, the
context menu should be ordered like in Mozilla.
6. New Style of Selecting and Managing Sidebar Panels using a
Single-Selection Dropdown List
(http://bugzilla.mozilla.org/show_bug.cgi?id=209642)
7. Make the f9 key open the sidebar.
(http://bugzilla.mozilla.org/show_bug.cgi?id=184565)
--
Peter Lairo
--==--
The trend of an internet accessible only by Windows users running
Internet Explorer is both disgusting and frightening. (Scott Remick)
--==--
Michael Lefevre
> Peter Lairo meinte am 6/17/2003 1:35 PM:
>
>> Definetely!
>>
>> We need (as a minimum):
>> 1. "Send Link" in FB should use TB (prolly handled by OS? If not, a
>> pref!). Therefore, also:
>> 2. Shared Addressbook
>> 3. TB: middle-click opens in new tab (this is a biggie).
>> 4. Digital Certificates (e.g., Thawte: https://www.thawte.com/home.html)
>
> novices couldn't install their prefered plugins (eg. messageid-finder or
> mnenhy) which only works within Mozilla Mail / Thunderbird.
novices shouldn't be using Thunderbird 0.1...
if they wait for all that stuff to get done, we won't see a release for
another 5 years...
--
Michael
Henrik Skupin
> novices shouldn't be using Thunderbird 0.1...
Instead they should use which application? There is no other mail-client
within the Mozilla project they could switch to. Thats the aim of
splitting the mozilla application suite? ´We don't need more users and
when you can't handle thunderbird leave the project'? Microsoft will be
glad about. :(
> if they wait for all that stuff to get done, we won't see a release for
> another 5 years...
Not all stuff but the most which is needed. And the installation of
additional extensions is necessary in my opinion because there is no
existing browser component which will do it for. The manual installation
isn't really satisfying.
--
Hierarchie dt. Mozilla-Newsgroups: news://de.comm.software.mozilla.*
FAQ: http://www.graphity.info/mozilla/dcsmx-faq.txt
Mozilla-FAQ: http://www.holgermetzger.de/faq.html
Best of Addons: http://hskupin.info/mozilla/addons.php
Simon Paquet
>> Definetely!
>>
>> We need (as a minimum):
>> 1. "Send Link" in FB should use TB (prolly handled by OS? If not,
>> a pref!). Therefore, also:
Send Link should use the Default Mail Client, which should be
configurable via Tools-Options.
>> 2. Shared Addressbook
Bullshit. We do not need an adressbook in Firebird.
>> 3. TB: middle-click opens in new tab (this is a biggie).
It would be nice, but it ain't a biggie.
> And additional for Thunderbird the xpi-installer! Without it
> many novices couldn't install their prefered plugins (eg.
> messageid-finder or mnenhy) which only works within Mozilla
> Mail/Thunderbird.
Extension install has been implemented in Thunderbird (see
http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2Fmail&date=week)
I don't know if there are some modifications for an extension,
which are necessary for it to run under Thunderbird, but the
basic stuff has been done.
--
Simon Paquet
http://sipaq.blogspot.com - Mein Mozilla Blog
Gervase Markham
> On 6/16/03 5:44 PM, Gervase Markham wrote:
>> - When do we stop shipping Seamonkey?
>
> When there is (near) *feature parity* between Mozilla Suite and FB/TB ?
No. :-) "When it's possible to add most of the features of the Mozilla
suite to Firebird as extensions" might be more what you mean. And that
may not necessarily be true either.
Gerv
Michael Lefevre
> Michael Lefevre meinte am 6/17/2003 2:41 PM:
>
>> novices shouldn't be using Thunderbird 0.1...
>
> Instead they should use which application? There is no other mail-client
> within the Mozilla project they could switch to. Thats the aim of
> when you can't handle thunderbird leave the project'? Microsoft will be
> glad about. :(
Well at the moment they could use Mozilla 1.3.1, or Netscape 7.02.
Mozilla 1.4 isn't even out yet, but when it is, they could use that.
Why do you think people need to switch right now? I don't know what
novices you are talking about, but most novices I know don't want to
change software every few weeks.
>> if they wait for all that stuff to get done, we won't see a release for
>> another 5 years...
>
> Not all stuff but the most which is needed.
[snip]
ok, so maybe just wait for a year instead of five...
--
Michael
Stefan Borggraefe
> Michael Lefevre meinte am 6/17/2003 2:41 PM:
>>novices shouldn't be using Thunderbird 0.1...
>
> Instead they should use which application? There is no other mail-client
> within the Mozilla project they could switch to. Thats the aim of
> splitting the mozilla application suite? ´We don't need more users and
> when you can't handle thunderbird leave the project'? Microsoft will be
> glad about. :(
I'm quite sure your copy of Mozilla 1.4 won't be magically deleted from
your harddrive even if there are no more releases after that. ;-)
So you can use this for a while and switch to Thunderbird when it has
matured a bit.
Greetings, Stefan!
Henrik Skupin
> Extension install has been implemented in Thunderbird (see
> http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2Fmail&date=week)
Great. That's all what i ment. I see that i don't have to wait one year! ;)
> I don't know if there are some modifications for an extension,
> which are necessary for it to run under Thunderbird, but the
> basic stuff has been done.
It could be if some interfaces were changed which the extensions need. I
will test it when an actual nighlty is avaible.
Peter Lairo
> Peter Lairo wrote:
>
>> On 6/16/03 5:44 PM, Gervase Markham wrote:
>>
>>> - When do we stop shipping Seamonkey?
>>
>> When there is (near) *feature parity* between Mozilla Suite and FB/TB ?
>
> No. :-) "When it's possible to add most of the features of the Mozilla
> suite to Firebird as extensions" might be more what you mean.
That's definetely not what I mean. I already spend more time than I like
adding useful features to Mozilla after each install (optimoz,
spellcheck, JSLib, TagZilla , ...). At the current rate at which FB/TB's
features are *not* being added, it would take an annoying amount of
effort and time to achieve this. I'm not looking forward to installing a
bazillion extensions and then still missing many dear-to-me features
that Mozilla has. :(
It's not as bad as I'm making it sound, but I'm currently *very* skeptical.
> And that
> may not necessarily be true either.
That would be very unfortunate. Completely leaving out some of Mozilla's
useful features would be very unfortunate. :(
Time will tell... :)
--
Peter Lairo
--==--
Welcome to the "Corporate States of America"
--==--
Peter Lairo
> Henrik Skupin wrote:
>
>
>>>Definetely!
>>>
>>>We need (as a minimum):
>>>1. "Send Link" in FB should use TB (prolly handled by OS? If not,
>>> a pref!). Therefore, also:
>
> Send Link should use the Default Mail Client, which should be
> configurable via Tools-Options.
Isn't that defined in the OS?
>>>2. Shared Addressbook
>
> Bullshit. We do not need an adressbook in Firebird.
True. I suppose (and hope) that once the compose window of the "default
e-mail client" comes up, users will be able to access the addressbook of
that e-mail client. :-\
>>>3. TB: middle-click opens in new tab (this is a biggie).
>
> It would be nice, but it ain't a biggie.
It is a biggie to me! (Sorry for overgeneralizing)
>>And additional for Thunderbird the xpi-installer! Without it
>>many novices couldn't install their prefered plugins (eg.
>>messageid-finder or mnenhy) which only works within Mozilla
>>Mail/Thunderbird.
>
> Extension install has been implemented in Thunderbird (see
> http://bonsai.mozilla.org/cvsquery.cgi?dir=mozilla%2Fmail&date=week)
So an extension installer is in the current nighlies?
Henrik Skupin
>>Send Link should use the Default Mail Client, which should be
>>configurable via Tools-Options.
>
> Isn't that defined in the OS?
Not at all. AFAIK Linux has some problems with it and it could only
resolved with the help of the ´context extensions' which sets the
default mail client from an property.
Probably an pref with this way is acceptable. If it is empty the OS
should do the job.
> So an extension installer is in the current nighlies?
Not yet released. The last nightly is 6 days old. :/
CG
Michael Lefevre wrote:
> In article <3EEF052...@hskupin.info>, Henrik Skupin wrote:
>> Peter Lairo meinte am 6/17/2003 1:35 PM:
>>
>>> Definetely!
>>>
>>> We need (as a minimum):
>>> 1. "Send Link" in FB should use TB (prolly handled by OS? If not, a
>>> pref!). Therefore, also:
>>> 2. Shared Addressbook
>>> 3. TB: middle-click opens in new tab (this is a biggie).
>>> 4. Digital Certificates (e.g., Thawte: https://www.thawte.com/home.html)
>>
>> And additional for Thunderbird the xpi-installer! Without it many
>> novices couldn't install their prefered plugins (eg. messageid-finder or
>> mnenhy) which only works within Mozilla Mail / Thunderbird.
>
> novices shouldn't be using Thunderbird 0.1...
Perhaps that was worded incorrectly. "Novices -> Users".
> if they wait for all that stuff to get done, we won't see a release for
> another 5 years...
>
--
Chris Garcia
MCSE - Cisco/A+ Certified - Novell MCNE
Netscape/Mozilla FAQS - http://www.UFAQ.org
** Post To Group Only - No Email Please **
Gervase Markham
>> No. :-) "When it's possible to add most of the features of the Mozilla
>> suite to Firebird as extensions" might be more what you mean.
>
> That's definetely not what I mean. I already spend more time than I like
> adding useful features to Mozilla after each install (optimoz,
> spellcheck, JSLib, TagZilla , ...). At the current rate at which FB/TB's
> features are *not* being added, it would take an annoying amount of
> effort and time to achieve this. I'm not looking forward to installing a
> bazillion extensions and then still missing many dear-to-me features
> that Mozilla has. :(
Then either:
a) Upgrade less frequently
b) write a tool which installs a load of XPIs at once (a meta-XPI? :-)
That would be very cool.
c) Have a "browsing" copy of Mozilla and a "testing" copy, and upgrade
the browsing one less frequently.
Also, it may turn out that some extensions ship, but are disabled - so
all you'll have to do is enter the prefs and turn them on.
> That would be very unfortunate. Completely leaving out some of Mozilla's
> useful features would be very unfortunate. :(
They are useful to you; not perhaps to everyone. Hence the concept of
extensions :-)
Gerv
Peter Lairo
> Peter Lairo wrote:
>
>>> No. :-) "When it's possible to add most of the features of the
>>> Mozilla suite to Firebird as extensions" might be more what you mean.
>>
>> That's definetely not what I mean. I already spend more time than I
>> like adding useful features to Mozilla after each install (optimoz,
>> spellcheck, JSLib, TagZilla , ...). At the current rate at which
>> FB/TB's features are *not* being added, it would take an annoying
>> amount of effort and time to achieve this. I'm not looking forward to
>> installing a bazillion extensions and then still missing many
>> dear-to-me features that Mozilla has. :(
>
> Then either:
>
> a) Upgrade less frequently
I only upgrade 1/week, so any less would not fulfil my desire to
adequately bug test (also, to quench my eager anticipation of new
features - notice, *not* critical bugfixes, as IMO there are none as
relevant as new features) ;)
> b) write a tool which installs a load of XPIs at once (a meta-XPI? :-)
> That would be very cool.
Very coll indeed! :-D Alas, I cannot write such a tool. :(
Great would be the ability to set up a *group of favorite extensions*,
and then the ability to *save this group* as a file/bookmark/whatever
for future use. ;)
> c) Have a "browsing" copy of Mozilla and a "testing" copy, and upgrade
> the browsing one less frequently.
I test by browsing. How else could it be done. :-\
> Also, it may turn out that some extensions ship, but are disabled - so
> all you'll have to do is enter the prefs and turn them on.
The (off by default) shipping extensions should be those that can at
least bring FB/TB into parity with Mozilla Suite.
>> That would be very unfortunate. Completely leaving out some of
>> Mozilla's useful features would be very unfortunate. :(
>
> They are useful to you; not perhaps to everyone. Hence the concept of
> extensions :-)
And here lies a danger of the current extensions "philosophy":
Take out everything that not (almost) *everybody* uses and you are left
with a barebones browser where *too many* (some critical number of
users) have to re-add a bunch of extensions*. People *hate* extra effort. :(
My impression was that Mozilla was bloated *code-wise*, and that *some*
UI was poorly designed. I don't think FB/TB should be reducing features
to achieve a goal that *can be* orthogonal to the original problems. It
is possible (IMHO) to eliminate the *code bloat* and fix the UI issues
*without* sacrificing features.
PS. I think I may have used to many *emphases*, if so - sorry. :-\
--
Peter Lairo
Newsgroup for end-user discussion and peer support:
snews://secnews.netscape.com:563/netscape.mozilla.user.general
Mozilla Guide: http://www.mozilla.org/start/1.0/guide/
pascal chevrel
> b) write a tool which installs a load of XPIs at once (a meta-XPI? :-)
> That would be very cool.
It already exists :
http://asbin.free.fr/mozilla/installeur/
Pascal
Boris Zbarsky
> My impression was that Mozilla was bloated *code-wise*
Yes. The most bloated part of the code was the UI. Note that Firebird
and Seamonkey are still sharing the same back end, so any bloat
reductions Firebird claims are solely due to UI bloat.
> and that *some* UI was poorly designed.
And almost all of it poorly implemented (not initially, but cruft got
layered as time went on).
> It is possible (IMHO) to eliminate the *code bloat*
The *code bloat* that Firebird is trying to fix can be summarized as:
"too many lines of XUL/js code".
-Boris
Christian Biesinger
> Not at all. AFAIK Linux has some problems with it
Well, Linux has no concept of a system default mailer.
> and it could only
> resolved with the help of the ´context extensions' which sets the
> default mail client from an property.
"an property"? What kind of property? Doesn't it let the user choose a
mailer, presumably storing that choice as a pref?
Henrik Skupin
> "an property"? What kind of property? Doesn't it let the user choose a
> mailer, presumably storing that choice as a pref?
Sorry, you are right. Just my fault. ;)
Calum Mackay
> It could be if some interfaces were changed which the extensions need. I
> will test it when an actual nighlty is avaible.
If anyone cares, I'm uploading nightly GTK2/XFT builds of the mozilla
appsuite, firebird & thunderbird, for Linux/x86, to:
http://rykros.ath.cx/~calum/mozilla/
cheers,
c.
Brant Langer Gurganus
>
> a) Upgrade less frequently
> b) write a tool which installs a load of XPIs at once (a meta-XPI? :-)
> That would be very cool.
Write one that that will download an XML or other type of file listing
available extensions, their versions, and locations. Record downloaded
versions and then offer a manage, install, update tab. Or improve on
the build-in extension mechanism to do this from a URL on mozdev or
something (probably mozdev default but user-configurable).
>
> c) Have a "browsing" copy of Mozilla and a "testing" copy, and upgrade
> the browsing one less frequently.
--
Brant Langer Gurganus
Default QA Contact, Calendar
Default QA Contact, Tech Evangelism
Peter Lairo
> Peter Lairo wrote:
>
>> My impression was that Mozilla was bloated *code-wise*
>
> Yes. The most bloated part of the code was the UI.
That's still *code* and not *features*.
>> and that *some* UI was poorly designed.
>
> And almost all of it poorly implemented (not initially, but cruft got
> layered as time went on).
That's still *code* and not *features*.
> > It is possible (IMHO) to eliminate the *code bloat*
>
> The *code bloat* that Firebird is trying to fix can be summarized as:
> "too many lines of XUL/js code".
That's still *code* and not *features*.
My inital point still stands:
*It is possible IMHO to eliminate the code bloat and fix the UI issues
without sacrificing features*.
Thank you for implicitly confirming my main point. :)
--
Peter Lairo
Peter Lairo
Seems nice (didn't test). Would be useful to me *if* it included many
more addons, at least the ones that I regularly add:
- Optimoz (http://optimoz.mozdev.org/gestures/installation.html)
- Calendar (http://www.mozilla.org/projects/calendar/)
- Spellchecker (+ German Dict.)
(http://spellchecker.mozdev.org/installation.html)
- JSLib (http://jslib.mozdev.org/installation.html)
- TagZilla (http://tagzilla.mozdev.org/installation.html)
Gervase Markham
Cool :-) Here's a suggestion for an improvement - either by you or
someone else. Have a list of every extension you can find. Allow people
to select a subset, and produce a page like
http://asbin.free.fr/mozilla/installeur/ with them on, and then either
let them bookmark it or store a cookie with their set.
So, every time I reinstall, I can return to the page and click "Install
XPIs" from my personal custom list.
Gerv
Gervase Markham
> Henrik Skupin wrote:
>
>> Not at all. AFAIK Linux has some problems with it
>
> Well, Linux has no concept of a system default mailer.
Actually, it does - the MAILER environment variable. But that may not be
appropriate for this particular use.
Gerv
Henrik Skupin
> So, every time I reinstall, I can return to the page and click "Install
> XPIs" from my personal custom list.
I'm on the way... perhaps also as a multilingual page. But first i have
to talk with asbin.
Robb Tolliver
> We need (as a minimum):
> 1. "Send Link" in FB should use TB (prolly handled by OS? If not, a
> pref!).
My understanding is that mozilla (AppSuite) uses sockets to communicate
between its processes (threading). Couldn't Fb and Tb use sockets to communicate?
I know very little about sockets and threading, so i could be way off here..
--
~Robb
Boris Zbarsky
>> The *code bloat* that Firebird is trying to fix can be summarized as:
>> "too many lines of XUL/js code".
>
> That's still *code* and not *features*.
The point is that features require code to implement. Some very minor
and rarely-used features require a LOT of code to implement. In those
circumstances, removing them may make sense.
> Thank you for implicitly confirming my main point. :)
Thank you for hearing only what you want to hear. That always helps in
a discussion.
-Boris
Karsten Düsterloh
> The point is that features require code to implement. Some very minor
> and rarely-used features require a LOT of code to implement. In those
> circumstances, removing them may make sense.
May. Actually, I don't think so.
If a feature has been released with an "official" Mozilla, it should
stay. Mere size can't be the point these days anymore!
(And yes, I have an old and slow PC.)
> Thank you for hearing only what you want to hear. That always helps in
> a discussion.
Just as removing features without any discussion at all.
Karsten
--
Freiheit stirbt | Fsayannes SF&F-Bibliothek:
Mit Sicherheit | http://fsayanne.tprac.de/
Christopher Seawood
> Boris Zbarsky aber hob zu reden an und schrieb:
>
>>The point is that features require code to implement. Some very minor
>>and rarely-used features require a LOT of code to implement. In those
>>circumstances, removing them may make sense.
>
>
> May. Actually, I don't think so.
> If a feature has been released with an "official" Mozilla, it should
> stay. Mere size can't be the point these days anymore!
> (And yes, I have an old and slow PC.)
Mere size is still a very good point. Just because we have faster
machines doesn't mean we should waste cycles on useless items. What
good is a faster machine if your application grows as well, practically
eliminating the benefits of getting a faster machine?
If there was any standard measure of determining what went into an
official Mozilla build in the first place, you might have a point about
feature backward compatibility. However, I've seen a number of features
get added to the tree because a handful of people happened to think it
was "cool" or "for testing" and not because it was the best thing for
the users of the application. Why does an end-user browser appsuite
need a terminal app, irc client, js debugger or dom inspector? At some
point, we need to say, "Enough." and move those items which are clearly
external to the core interests of the project to an external venue or at
least detach them from the core project.
>
>>Thank you for hearing only what you want to hear. That always helps in
>>a discussion.
>
>
> Just as removing features without any discussion at all.
What features were removed without *any* discussion at all? Or by
"any", do you mean without your participation or the participation of
others who aren't working on the code in question? And would it really
matter how much the issue was discussed if the outcome was the same?
- cls
Boris Zbarsky
> If a feature has been released with an "official" Mozilla, it should
> stay. Mere size can't be the point these days anymore!
> (And yes, I have an old and slow PC.)
That's not actually that relevant. A bigger problem of too much code is
that it becomes nearly impossible to make changes and write new code.
I'm not saying features MUST be removed, just that there may be good
reasons to do it.
>>Thank you for hearing only what you want to hear. That always helps in
>>a discussion.
>
> Just as removing features without any discussion at all.
Just as accusing people of things for no reason (hint: name one feature
I have removed from a piece of software you use).
Cheers,
Boris
Karsten Düsterloh
>> stay. Mere size can't be the point these days anymore!
>> (And yes, I have an old and slow PC.)
>
> That's not actually that relevant. A bigger problem of too much code is
> that it becomes nearly impossible to make changes and write new code.
>
> I'm not saying features MUST be removed, just that there may be good
> reasons to do it.
Agreed. We may have different opinions about "good reasons", though.
>> Just as removing features without any discussion at all.
>
> Just as accusing people of things for no reason (hint: name one feature
> I have removed from a piece of software you use).
To clarify that one: I did not mean you personally.
I'm sorry if you got that impression.
Christian Biesinger
> My understanding is that mozilla (AppSuite) uses sockets to
> communicate between its processes (threading).
"its processes"? What do you mean with that?
Karsten Düsterloh
>> If a feature has been released with an "official" Mozilla, it
>> should stay. Mere size can't be the point these days anymore! (And
>> yes, I have an old and slow PC.)
>
> Mere size is still a very good point. Just because we have faster
> machines doesn't mean we should waste cycles on useless items. What
> good is a faster machine if your application grows as well,
> practically eliminating the benefits of getting a faster machine?
That wouldn't make much sense, agreed.
But removing (maybe) "coming standards" like MNG with the main arguments
"size" and "noone uses it" seems not very reasonable to me.
And it doesn't further trust into the coming "strong module ownership".
> If there was any standard measure of determining what went into an
> official Mozilla build in the first place, you might have a point
> about feature backward compatibility. However, I've seen a number of
> features get added to the tree because a handful of people happened
> to think it was "cool" or "for testing" and not because it was the
> best thing for the users of the application.
How will this be addressed by giving module owners even more power?
> Why does an end-user browser appsuite
--------
Huh?
> need a terminal app, irc client, js debugger or dom inspector?
A mere *browser* won't need them agreed.
But what's "browser appsuite" and who is its target user?
A power user might use/need the IRC client, a web designer may have use
for debugger and inspector...
> At some point, we need to say, "Enough." and move those items which
> are clearly external to the core interests of the project to an
> external venue or at least detach them from the core project.
A finer granulation of the modules is reasonable, no doubt.
But we shouldn't drop the "wholeness" of Mozilla the App Suite.
There's developers like me who like the big lizard for all its features
in one place. But if, say, every nightly requires a tedious reinstalling
a whole lot of so-called extensions, that's no fun anymore.
I don't object "end-user" browser packages.
But keep the big "all in one" Mozilla.
>> Just as removing features without any discussion at all.
>
> What features were removed without *any* discussion at all?
Any *public*, that is.
MailNews sidebar is a good example.
> Or by "any", do you mean without your participation
That would be a very self-centric claim - and I didn't make it.
> or the participation of others who aren't working on the code in
> question?
That does *extremely* sound like "we don't need no external input, piss
off". How do you want know what "the best thing for the users" is, then?
I've seen this attitude quite a lot in bugzilla, and it does really not
help anyone.
> And would it really matter how much the issue was discussed
> if the outcome was the same?
Yes, of course.
You could see the arguments and reasons of both sides, maybe even
convince the "other side". Maybe you aren't in possession of the Holy
Grail, maybe you have overlooked something, maybe someone has
good/better idea!
Robb Tolliver
Mozilla (at least under linux) forks into several processes.
--
~Robb
Boris Zbarsky
> In windows ctrl+alt+del lists processes, In linux the pm commands lists
> them..
> Mozilla (at least under linux) forks into several processes.
Threads. 'ps' lists both processes and threads.
Robb Tolliver
Yeah, 'ps' that's what i meant..
I didn't realize that it listed threads as well, as I said before, i know very
little about threads..
Andrew Schultz
> Peter Lairo wrote:
>
>> We need (as a minimum):
>> 1. "Send Link" in FB should use TB (prolly handled by OS? If not, a
>> pref!).
>
>
> My understanding is that mozilla (AppSuite) uses sockets to
> communicate between its processes (threading). Couldn't Fb and Tb use
> sockets to communicate?
Right, but the different parts (windows) don't run in different threads. The
threads are used for DNS and other things I don't recall.
--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.
Christopher Seawood
> Christopher Seawood aber hob zu reden an und schrieb:
>
>>>If a feature has been released with an "official" Mozilla, it
>>>should stay. Mere size can't be the point these days anymore! (And
>>> yes, I have an old and slow PC.)
>>
>>Mere size is still a very good point. Just because we have faster
>>machines doesn't mean we should waste cycles on useless items. What
>> good is a faster machine if your application grows as well,
>>practically eliminating the benefits of getting a faster machine?
>
>
> That wouldn't make much sense, agreed.
> But removing (maybe) "coming standards" like MNG with the main arguments
> "size" and "noone uses it" seems not very reasonable to me.
> And it doesn't further trust into the coming "strong module ownership".
I'm not even going to get into that useless discussion about "coming
standards", things that "should be standard" and "wouldn't it be nice
if?" deadlock. Someone has to make a decision about these issue and
mozilla.org left it up to the module owners to decide such things. And
btw, "strong module ownership" is not a new concept. It's basically how
things have been happening since the inception of the project. You
didn't think all of these decisions were handed down from the top, did
you?
>
>>If there was any standard measure of determining what went into an
>>official Mozilla build in the first place, you might have a point
>>about feature backward compatibility. However, I've seen a number of
>> features get added to the tree because a handful of people happened
>> to think it was "cool" or "for testing" and not because it was the
>>best thing for the users of the application.
>
>
> How will this be addressed by giving module owners even more power?
I never asserted that strong module ownership would address the feature
creep problem. Strong module ownership would prevent the above problem
from occurring due to outside influences but it wouldn't address the
problem of the module owners themselves making questionable decisions.
>
>>Why does an end-user browser appsuite
>
> --------
> Huh?
>
>
>>need a terminal app, irc client, js debugger or dom inspector?
>
>
> A mere *browser* won't need them agreed.
> But what's "browser appsuite" and who is its target user?
> A power user might use/need the IRC client, a web designer may have use
> for debugger and inspector...
So we're targetting all of those users from a single product? Ambitious
and it's no wonder no one can agree on what's best for the project.
IMO, that's another major problem of the project, perceived lack of
focus. Who is the target user of the product? For quite a long time,
it was claimed that mozilla is "for testing only" and "not for
end-users". Obviously, somewhere down the line, this line of reasoning
has changed since we have Firebird which is obviously for end-users.
But we have these extra requirements of dom inspector & js debugger
which must be made available for firebird users before we could switch
to Firebird. So does that mean Firebird is for end-users &
web-developers? So where would that leave me (neither end-user nor
web-developer)?
>
>>At some point, we need to say, "Enough." and move those items which
>>are clearly external to the core interests of the project to an
>>external venue or at least detach them from the core project.
>
>
> A finer granulation of the modules is reasonable, no doubt.
> But we shouldn't drop the "wholeness" of Mozilla the App Suite.
Who is "we"? mozilla.org has apparently made their choice even though
people still claim that the new roadmap is "just a proposal". That
doesn't mean that all of the developers working on the project agree
with or plan to follow that proposal.
> There's developers like me who like the big lizard for all its features
> in one place. But if, say, every nightly requires a tedious reinstalling
> a whole lot of so-called extensions, that's no fun anymore.
What's preventing you from helping to maintaining (and even enhance) the
current app-suite? Even if you wanted to build a suite out of the "new
world" apps, it should be possible to set up the system so that you
install extensions in a common directory once and it's available for all
apps which use the GRE. In fact, I believe that's the topic of
discussion in another current thread in this group.
>>>Just as removing features without any discussion at all.
>>
>>What features were removed without *any* discussion at all?
>
>
> Any *public*, that is.
Define public. Bugzilla? Newsgroups? Mozillazine forum? Pop-up on the
mozilla.org/start page?
> MailNews sidebar is a good example.
I'm actually unaware of that issue so I can't comment on it.
>>or the participation of others who aren't working on the code in
>>question?
>
>
> That does *extremely* sound like "we don't need no external input, piss
> off".
Actually, it's more of a "put your money/time/effort where your mouth
is" (or when I'm in a less generous mood "lead, follow or get the fuck
out of the way").
> I've seen this attitude quite a lot in bugzilla, and it does really not
> help anyone.
And having a *lot* of people give their uninformed, personal opinion
about a technical matter or whining like a 4 year old when they don't
get their way *does* help? Sure, *everyone* has an opinion about any
given topic. However, not everyone has a *useful* opinion about said
topic. Again, you have to draw the line somewhere.
Putting my question back into context, almost anything would be better
than letting dicussions be derailed by a bunch of feature advocates who
really have nothing hanging in the balance either way when it comes to
the code/feature in question. I see nothing wrong with having the
people who *do* have something riding on the feature partake in the
discussion. It does become hard to make that sort of distinction
without using something arbitrary (like writing code) to distinguish
between the two groups. Open source advocates are notoriously bad when
it comes to demanding features or conformance to their own set of
ideals. And of course, they ignore the fact that there's nothing about
open-source code that guarantees that things will be the way you like
unless you write/modify it yourself.
> How do you want know what "the best thing for the users" is, then?
Talk to users? Take a poll? Listen to mpt? It really doesn't matter as
you could argue in either direction about any sample size. For example,
bugzilla users do not represent the typical end-user or for the 50,000
bugzilla users who *didn't* object to the removing of MNG, does that
mean they were for it? *Start the descent into further insanity....*
>
>>And would it really matter how much the issue was discussed
>>if the outcome was the same?
>
>
> Yes, of course.
> You could see the arguments and reasons of both sides, maybe even
> convince the "other side". Maybe you aren't in possession of the Holy
> Grail, maybe you have overlooked something, maybe someone has
> good/better idea!
You missed the point...namely that the outcome was the same. To
clarify, let's say that you've presented your arguments and reasons for
both/all sides of the issue and the end results were still the same. Do
you still feel as though there was sufficient discussion on the matter
or will you only get that feeling when you've managed to change the
outcome? That was the real scenario I meant to propose.
My impression is that no matter how much discussion is made on the MNG
issue, it's not going to be enough for the MNG advocates unless the
decision is reversed. Turning the MNG decoder into a mozdev project and
figuring out how to integrate it with the existing mozdev(?) extension
manager would be a better use of resources, IMO.
- cls
Boris Zbarsky
> But we have these extra requirements of dom inspector & js debugger which must be
> made available for firebird users before we could switch to Firebird. So
> does that mean Firebird is for end-users & web-developers?
I think the reason we have those requirements (certainly the reason that
_I_ have been pushing for them) is that they make QA, bug triage,
development of XUL applications, and development of the layout engine,
in some cases, much easier. The requirements are there so that we can
usefully manage inflow of bug reports while eating dogfood, not because
we need those tools as part of the browser per se.
Apart from that, I wholeheartedly agree!
-Boris
James Graham
> Gervase Markham wrote:
>
>>
>> a) Upgrade less frequently
>> b) write a tool which installs a load of XPIs at once (a meta-XPI? :-)
>> That would be very cool.
>
>
> Write one that that will download an XML or other type of file listing
> available extensions, their versions, and locations. Record downloaded
> versions and then offer a manage, install, update tab. Or improve on
> the build-in extension mechanism to do this from a URL on mozdev or
> something (probably mozdev default but user-configurable).
>
That sounds a lot like the direction that Extension Manager is heading.
See http://forums.mozillazine.org/viewtopic.php?t=13194 for more details.
Karsten Düsterloh
> mozilla.org left it up to the module owners to decide such things.
So if the owner makes some very stupid decisions, let's say remove *all*
graphics, that'd be fine by mozilla.org, because he's the module owner?
I do not believe this, sorry.
>> How will this be addressed by giving module owners even more power?
>
> I never asserted that strong module ownership would address the feature
> creep problem. Strong module ownership would prevent the above problem
> from occurring due to outside influences but it wouldn't address the
> problem of the module owners themselves making questionable decisions.
Okay.
> Who is the target user of the product? For quite a long time,
> it was claimed that mozilla is "for testing only" and "not for
> end-users". Obviously, somewhere down the line, this line of reasoning
> has changed since we have Firebird which is obviously for end-users.
Then you should state this clearly:
The future Mozilla is for end-users.
But that will of course disappoint many of the current app suite's users.
> But we have these extra requirements of dom inspector & js debugger
> which must be made available for firebird users before we could switch
> to Firebird. So does that mean Firebird is for end-users &
> web-developers? So where would that leave me (neither end-user nor
> web-developer)?
That's the same question I ask myself.
(I'm, too, neither end-user nor web-developer.)
Firebird ('s UI) is plainly too dumb for my usage, it still lacks too
many features/pref possibilities I'm accustomed from Mozilla.
And I don't want to install a whole lot of extensions or different apps
just to get it somewhat usable, so I guess I'll stick with 1.4 for a while.
But I see the maintainance problems with the app suite and think that
the finer module granulation is a good thing.
>> A finer granulation of the modules is reasonable, no doubt.
>> But we shouldn't drop the "wholeness" of Mozilla the App Suite.
>
> Who is "we"?
"We" Mozilla-using/building/programming people.
Mozilla "addicts" are still (and will be for the foreseeable future) a
minority "out there".
> mozilla.org has apparently made their choice even though
> people still claim that the new roadmap is "just a proposal". That
> doesn't mean that all of the developers working on the project agree
> with or plan to follow that proposal.
I see...
>> There's developers like me who like the big lizard for all its features
>> in one place. But if, say, every nightly requires a tedious reinstalling
>> a whole lot of so-called extensions, that's no fun anymore.
>
> What's preventing you from helping to maintaining (and even enhance) the
> current app-suite?
Nothing, of course.
biesi has already volunteered to do that, and I'm willing to help.
>> Any *public*, that is.
>
> Define public. Bugzilla? Newsgroups? Mozillazine forum? Pop-up on the
> mozilla.org/start page?
Anywhere "at Mozilla.org" where interested folks have a chance to
participate without having to be there at the right second.
Bugzilla and NGs are fine, Mozillazine is already somewhat outside.
But decisions over IRC or in the Netscape Cantina are definitely not
very transparent...
> "lead, follow or get the fuck out of the way"
At least, it's very comprehensible. ;-)
But it does not have space for suggestions.
Suggestions by the leader are the "fact", followers are just that and
don't suggest, and everyone else is "irrelevant".
>> I've seen this attitude quite a lot in bugzilla, and it does really not
>> help anyone.
>
> And having a *lot* of people give their uninformed, personal opinion
> about a technical matter or whining like a 4 year old when they don't
> get their way *does* help?
No, of course not.
I've seen too many of this in Bugzilla and I'm also tired of it.
But how shall anyone get informed, if decisions come out of the blue
sky? You get just hit by it, often with "strange" to none reasoning.
"And HE saw it and HE found it must go and so HE made it vanish."
> Sure, *everyone* has an opinion about any
> given topic. However, not everyone has a *useful* opinion about said
> topic. Again, you have to draw the line somewhere.
Yeah, of course.
But the perimeter fence shouldn't be the Netscape campus, if you claim
to have a "community".
> I see nothing wrong with having the
> people who *do* have something riding on the feature partake in the
> discussion. It does become hard to make that sort of distinction
> without using something arbitrary (like writing code) to distinguish
> between the two groups. Open source advocates are notoriously bad when
> it comes to demanding features or conformance to their own set of
> ideals. And of course, they ignore the fact that there's nothing about
> open-source code that guarantees that things will be the way you like
> unless you write/modify it yourself.
Agreed.
> > How do you want know what "the best thing for the users" is, then?
>
> Talk to users? Take a poll? Listen to mpt? It really doesn't matter as
> you could argue in either direction about any sample size. For example,
> bugzilla users do not represent the typical end-user or for the 50,000
> bugzilla users who *didn't* object to the removing of MNG, does that
> mean they were for it? *Start the descent into further insanity....*
The method of listening isn't important, just the *listening*.
And reasonable explanations for unpopular decisions.
And regarding MNG:
Most /end-users/ don't care for any grahics format, as long their
browser displays it. I don't care for MNG, I'm just against the "how" it
was removed.
> You missed the point...namely that the outcome was the same. To
> clarify, let's say that you've presented your arguments and reasons for
> both/all sides of the issue and the end results were still the same. Do
> you still feel as though there was sufficient discussion on the matter
> or will you only get that feeling when you've managed to change the
> outcome? That was the real scenario I meant to propose.
If the outcome isn't what I had wished for, I'd not be happy, of course.
But if all relevant arguments have been on the table, and the *deciding*
reasons are stated, I'm content with the /process/.
("Because I feel so." shouldn't be the base of a decision, though.)
> My impression is that no matter how much discussion is made on the MNG
> issue, it's not going to be enough for the MNG advocates unless the
> decision is reversed.
Probably true.
But many people have started using MNG, because Mozilla supported it.
And now they see their potential users vanish. I do understand their
annoyment.
> Turning the MNG decoder into a mozdev project and
> figuring out how to integrate it with the existing mozdev(?) extension
> manager would be a better use of resources, IMO.
I don't think that browsers should have a need for extensions to display
graphics.
The MNG decision is just a symptom.
Peter Lairo
> Peter Lairo wrote:
>
>> Thank you for implicitly confirming my main point. :)
>
> Thank you for hearing only what you want to hear. That always helps in
> a discussion.
Your welcome. ;) (i was being *funny* - hence the smiley!)
--
Regards,
Peter Lairo
Peter Lairo
> Gervase Markham meinte am 18.06.2003 16:20:
>
>>So, every time I reinstall, I can return to the page and click "Install
>>XPIs" from my personal custom list.
>
> I'm on the way...
OK, *now* i'm starting to get more excited about MFB&MTB. :-D
--
Regards,
Peter Lairo
Christopher Blizzard
> Christian Biesinger wrote:
>
>> Robb Tolliver wrote:
>>
>>> My understanding is that mozilla (AppSuite) uses sockets to
>>> communicate between its processes (threading).
>>
No, threads share the same address space so they don't use sockets to
communicate. You just reference the memory directly in most cases (with
the proper synchronization, of course.)
>>
>>
>> "its processes"? What do you mean with that?
>>
> In windows ctrl+alt+del lists processes, In linux the pm commands
> lists them..
The command is 'ps'.
>
> Mozilla (at least under linux) forks into several processes.
No, we use multiple threads which are not the same thing as several
processes.
--Chris
riscky
Reading this thread makes me wonder... how has the MozillaApp Suite
gotten this far with all the whining and complaining. Everyone thinks
what they use everyday should be included, I suppose this leads to the
kitchen sink mentality which Mozilla Firebird was/is supposed to solve.
To me the easy, logical fix for some of these what should be extensions
and what should be included with Mozilla Firebird comes down to two
things. What is absolutely critical for to include for each build type.
Nightly builds are NOT for end users and thus adding stuff like a DOM
inspector and JS debugger seem to a logical inclusion. The DOM inspector
and debugger should then be left out for release and milestone builds.
Why isn't this a option worth exploring.
Oh and about MNG’s I could care less one way of the other. However from
what I have read the biggest use of MNG's where not on webpage's with in
particular themes to help polish up the UI. With that in mind sure it
seems silly to remove it... since it could be thought of as a critical
component in creating a stunning UI. For better or worse it was decide
the trade off of reducing *bloat* (as some people call it) was worth it.
People always want to complain that about lose of some minor
functionality they never knew existed but love to complain about size,
memory requirements and speed. Personally I worry more about extensions
working cross-platforms more than feature erosion.
syd logan
processes.
syd
Robb Tolliver wrote:
--
Syd Logan
Principal Engineer, AOL
Office: 858-618-2217
AIM: slogan621
e-mail: s...@netscape.com
Robb Tolliver
> What is absolutely critical for to include for each build type.
> Nightly builds are NOT for end users and thus adding stuff like a DOM
> inspector and JS debugger seem to a logical inclusion. The DOM inspector
> and debugger should then be left out for release and milestone builds.
> Why isn't this a option worth exploring.
I agree the builds should include different stuff for the different users
they are targeted to. End-users should get only things they need and
developers/testers should get the things they need without having to add a
bunch of extensions. I also think the idea of meta-extension installation
rocks. Extension-room and/or Firebird help should have the facilities to do
this on their sites.
Robb Tolliver
> Last I checked, on Linux, threads are implemented as (lightweight)
> processes.
That's what I thought too.. hence my confusion. So I was right?
Anyway I like the idea of having firebird and thunderbird use the default
mail client/browser, instead of relying on each other. Perhaps thunderbird
could invoke the default browser with a %s in the command. ex.
"MozillaFirebird -remote OpenURL(%s, new-tab)" Thunderbird could invoke the
command (supplied by the user as a pref), by replacing "%s" with the url of
the clicked link.
KaiRo - Robert Kaiser
>>it was claimed that mozilla is "for testing only" and "not for
>>end-users". Obviously, somewhere down the line, this line of reasoning
>>has changed since we have Firebird which is obviously for end-users.
>
>
> Then you should state this clearly:
>
> The future Mozilla is for end-users.
>
> But that will of course disappoint many of the current app suite's users.
Like me.
And like lots of people who supported the project by helping with
reporting bugs, doing triaging, entering their proposals into Bugzilla,
doing themes or localizations, or even some development work. Those all
tend *not* to be "end-users".
If I were a project manager, I'd make such a decision to piss off the
uncomfortable people in favor of the easy-to-handle "Joe User" kind of
people. Despite this I don't think the mozilla.org decision was made
with that intent.
I believe future "Mozilla" releases should contain the main apps along
with a big set of extensions which resemble the current (or even more)
functionality but are almost all deactivated by default (and therefore
shouldn't be a performande or memory problem). Along with them we should
have standalone releases of Browser and Mailnews, including only a small
set of extensions to have slim downloads (well, the online installer can
make all of them installable on-demand).
The problem is that we (talking of the Mozilla project) are pissing off
a big part of our user base, the power-users, with the move to the new
architecture if we're cutting off functionality that they started to
love. And they don't want to download 150 extension packs just to get
what they now download as one single .tar.gz or .zip file.
So, I'm all for it: Let's add a product that's targeted for end-users. I
liked having Phoenix/MozillaFirebird as a "member of the club" as long
as I knew that this is the end-user-targetted product, and my
power-user-product with the features I love is continued as well. Now
that I'll be forced to switch to the new base (as long as I want to keep
up with new development), I'm expecting the other product to support all
of that functionality in some way (and without pulling 15 mozdev
projects as well as my trunk tree and see the half of them broken by
trunk development).
If the new product can't satisfy this, I'll move over to another product
that can satisfy my needs better, and stop all my Mozilla work that I've
been doing up to now. I'm free to choose, thank god.
And no, I won't talk of MNG here, as this one alone would be a good
reason to fire up Konqueror *now*.
Robert Kaiser
Christopher Seawood
> Christopher Seawood aber hob zu reden an und schrieb:
>
>>Someone has to make a decision about these issue and
>>mozilla.org left it up to the module owners to decide such things.
>
>
> So if the owner makes some very stupid decisions, let's say remove *all*
> graphics, that'd be fine by mozilla.org, because he's the module owner?
> I do not believe this, sorry.
How does m.o's approval or disapproval change the fact that they've
given the decision making power to the module owners? The day-to-day
development of any particular module is in the hands of the module
owners not m.o. Sure, m.o can always come back and override a decision
made by the module owners if they feel like it, but that's not a common
occurrance.
>>Who is the target user of the product? For quite a long time,
>>it was claimed that mozilla is "for testing only" and "not for
>>end-users". Obviously, somewhere down the line, this line of reasoning
>>has changed since we have Firebird which is obviously for end-users.
>
>
> Then you should state this clearly:
>
> The future Mozilla is for end-users.
Yes, mozilla.org should come out and state this clearly.
>>"lead, follow or get the fuck out of the way"
>
>
> At least, it's very comprehensible. ;-)
>
> But it does not have space for suggestions.
> Suggestions by the leader are the "fact", followers are just that and
> don't suggest, and everyone else is "irrelevant".
That's interesting because I'm definitely not a "leader" in mozilla
development. I'm following the lead set forth by m.o but I do
occassionally (more frequently as of late) give suggestions. I suppose
I could fall into the irrelevant category but I really think you're
looking at it too much in terms of absolutes.
>>>I've seen this attitude quite a lot in bugzilla, and it does really not
>>>help anyone.
>>
>>And having a *lot* of people give their uninformed, personal opinion
>>about a technical matter or whining like a 4 year old when they don't
>>get their way *does* help?
>
>
> No, of course not.
> I've seen too many of this in Bugzilla and I'm also tired of it.
> But how shall anyone get informed, if decisions come out of the blue
> sky? You get just hit by it, often with "strange" to none reasoning.
> "And HE saw it and HE found it must go and so HE made it vanish."
Believe me, I know all about being hit by "out of the blue" reasoning
(i.e., the new roadmap). However, in the case of MNG (that was what we
were discussing at one point), that was not the case. It was discussed
in a public forum (bugzilla). It would have been nice if there was some
other sort of newsgroup announcement (I didn't see one) but as far as
being an open discussion for those interested in imglib bugs, I think
that was covered.
>>Sure, *everyone* has an opinion about any
>>given topic. However, not everyone has a *useful* opinion about said
>>topic. Again, you have to draw the line somewhere.
>
>
> Yeah, of course.
> But the perimeter fence shouldn't be the Netscape campus, if you claim
> to have a "community".
Since people beyond the Netscape campus have cvs accounts and are module
owners, I'm not certain how anyone could presume the line was drawn
anywhere near Netscape. In any case, our "community", like our source
tree, could use some dead wood removal.
> The method of listening isn't important, just the *listening*.
How do you know that people aren't being listened to? What metric are
you using other than the (non-)fulfullment of their particular demands?
> And reasonable explanations for unpopular decisions.
While that statement sounds reasonable on the surface, why do you
(people in general) feel as though you are _owed_ an explanation? If
you had put work on that particular piece of code or had some vested
interest in the code, I could understand that need if for nothing else
but closure. I'm not necessarily against providing reasonable
explanations for certain decisions but I don't think it will matter to
the advocates.
>>My impression is that no matter how much discussion is made on the MNG
>>issue, it's not going to be enough for the MNG advocates unless the
>>decision is reversed.
>
>
> Probably true.
> But many people have started using MNG, because Mozilla supported it.
> And now they see their potential users vanish. I do understand their
> annoyment.
I've heard that generalization before and I'm genuinely interested to
know which websites were using MNG because Mozilla supported it. Afaik,
only the MNG website used it.
>>Turning the MNG decoder into a mozdev project and
>>figuring out how to integrate it with the existing mozdev(?) extension
>>manager would be a better use of resources, IMO.
>
>
> I don't think that browsers should have a need for extensions to display
> graphics.
For standard graphics format, no, you shouldn't need an add-on.
However, MNG is not a standard graphics format. By that same reasoning,
flash should be built into the browser as well.
> The MNG decision is just a symptom.
Right, it's a symptom of multiple problems associated with the project
but what specifically do you think it's a sympton of?
- cls
KaiRo - Robert Kaiser
>>> MNG issue, it's not going to be enough for the MNG advocates unless
>>> the decision is reversed.
>>
>> Probably true.
>> But many people have started using MNG, because Mozilla supported it.
>> And now they see their potential users vanish. I do understand their
>> annoyment.
>
> I've heard that generalization before and I'm genuinely interested to
> know which websites were using MNG because Mozilla supported it. Afaik,
> only the MNG website used it.
Well, I thought that the bugs for removing (195280) and re-adding MNG
(18574) state some of them, but I didn't find URLs. What I did find in
there were people who used MNG for themes (Mozilla and/or Firebird) and
for some Mozilla-derived projects. Perhaps somebody also mentioned a
website - the only Problem is that it's not too useful in websites as
long as IE doesn't support it or the market share of a different
MNG-supporting browser gets higher (e.g. Konqueror). BTW, this is/was
the same for various DOM and CSS2 things that tend to be used more
frequently.
And don't talk of standards here as there is _no_ standards body for
images, AFAIK (having PNG as a W3C draft was not what the W3C was
intended for, and they did not follow that path any further).
BTW, I'd really love to use MNG for some graphics - but if not even
Mozilla does support it, I don't dare to use it...
>>> Turning the MNG decoder into a mozdev project and
>>> figuring out how to integrate it with the existing mozdev(?)
>>> extension manager would be a better use of resources, IMO.
>>
>> I don't think that browsers should have a need for extensions to display
>> graphics.
>
> For standard graphics format, no, you shouldn't need an add-on. However,
> MNG is not a standard graphics format. By that same reasoning, flash
> should be built into the browser as well.
Or removed completely. The difference is that built-in flash support
would be a common RFE if it was an open format - it's proprietary
though. MNG, OTOH, is an open format. And the new want-to-be maintainer
of Mozilla MNG support even knows ways to make imglib2 (aka libpr0n)
with MNG support smaller than the current libimg2. Just see bug 18574.
Anyway, the decision is being worked upon - see
http://bugzilla.mozilla.org/show_bug.cgi?id=18574#c131 (for my theory
about possible background to all of this, see my comment following
Gerv's one ;-> )
Robert Kaiser
Karsten Düsterloh
> module owners if they feel like it, but that's not a common
> occurrance.
And shouldn't be, of course.
>> Then you should state this clearly:
>>
>> The future Mozilla is for end-users.
>
> Yes, mozilla.org should come out and state this clearly.
Okay.
The question then is how to achieve this:
- by maintaining a "strong" (not bloated!) lizard, that can be stripped
down to light-weight end-user products, or
- by maintaining a light-weight product that needs adding a whole lot of
components to accomodate developers?
I think the first way is best, because it is more attractive for
"outsiders" to participate in developing Mozilla.
> However, in the case of MNG (that was what we were discussing at one
> point), that was not the case. It was discussed in a public forum
> (bugzilla). It would have been nice if there was some other sort of
> newsgroup announcement (I didn't see one) but as far as being an
> open discussion for those interested in imglib bugs, I think that was
> covered.
Yeah, but as I said, MNG isn't my point anyway.
> In any case, our "community", like our source tree, could use some
> dead wood removal.
Interesting wording. ;-)
>> The method of listening isn't important, just the *listening*.
>
> How do you know that people aren't being listened to? What metric
> are you using other than the (non-)fulfullment of their particular
> demands?
Of course it's hard to part listening and not-listening, if there's no
feedback...
>> And reasonable explanations for unpopular decisions.
>
> While that statement sounds reasonable on the surface, why do you
> (people in general) feel as though you are _owed_ an explanation?
"Owing" may be the wrong verb.
Maybe "people in general" just try to understand why?
> I'm not necessarily against providing reasonable explanations for
> certain decisions but I don't think it will matter to the advocates.
But it would help the others.
>> The MNG decision is just a symptom.
>
> Right, it's a symptom of multiple problems associated with the
> project but what specifically do you think it's a sympton of?
A sympton for the loss of communication.
Henrik Skupin
> Mind due, they can always use Evolution as their email client. It works
> quite well with Mozilla.
I know, but this is not the way to hold users...
Henrik Skupin
> OK, *now* i'm starting to get more excited about MFB&MTB. :-D
The first things about the project on mozdev you can find here:
http://installeur.mozdev.org/
Asbin will start with this project in this summer and i help him. So you
have to stay for a while.
drcaggiano
Benedikt Kantus
> The first things about the project on mozdev you can find here:
> http://installeur.mozdev.org/
>
> Asbin will start with this project in this summer and i help him. So you
> have to stay for a while.
Will there be an English translation someday? I'm having real
difficulties with French....
-Bene
--
"I am not bound to please thee with my answer."
The Merchant of Venice
Henrik Skupin
> Will there be an English translation someday? I'm having real
> difficulties with French....
At the moment it is only a placeholder without any sense. When the
project starts it will support different languages. Perhaps we need some
people for translating.
Boris 'pi' Piwinger
>> Will there be an English translation someday? I'm having real
>> difficulties with French....
>
> At the moment it is only a placeholder without any sense. When the
> project starts it will support different languages. Perhaps we need some
> people for translating.
I hope you can make sure that everything works under Linux
with only user privileges.
pi
Henrik Skupin
> I hope you can make sure that everything works under Linux
> with only user privileges.
Thats not in our hands. The installation of the selected extensions is
like you do local. Instead the autor of the extension has to implement
the two ways (global vs. profile) of installing.
Installateur will only collect all extensions which you wants to install
and run their setup - not more.
Henrik
Dustin Massop
Maybe if Evolution used Gecko instead of GtkHTML it would still benefit
Mozilla in general?
(Who knows if the Evolution developers would like the idea...) The
gtkhtml mailing list archives look pretty quiet:
http://lists.ximian.com/archives/public/gtkhtml/
I'm not asking anyone to agree with my opinion regarding Ximian's
business. I am also not exprienced with either library from a
programming point of view, (to put things in perspective.)
Personally, I don't like having separate news and mail clients and that
is one of the reasons I use Thunderbird instead of Evolution. That and
Thunderbird does mail and news very well (at least for my needs.)
Dustin