Shock as MozillaZine Readers Turn to Slashdot for Accurate Information

Thursday October 31st, 2002

For our last poll, we asked you where else you go to get Mozilla news. 848 of you answered with Slashdot getting 30% of the vote, almost twice as much as its nearest rival, MozillaNews, with 17%. The third-placed 'None of the above' option was favoured by 16% of you, which frankly tells us very little. FUD specialist MozillaQuest came in fifth with 8% of the vote, which concerns us slightly. 5% of you rely on mainstream tech news sites such as CNET's or eWeek while 4% of you prefer the weblog style of Blogzilla. Newcomers Planet Mozilla and MozFan didn't do so well with 1% and 0% of the vote respectively. NewsForge, with 1%, also did surprisingly badly, especially considering the amount of news we steal from them. Finally, 14% of you just go wherever telnet to port 80 will take you.

For our next poll, we'd like to know what your favourite Phoenix theme is. The options are taken from the lists at the mozdev Themes project and David Tenser's Phoenix Help so don't blame us if your favourite theme isn't listed. Go and vote now or just sit on the fence and watch the latest results.

#64 Re: Re: Another Example...

by asa <>

Friday November 1st, 2002 11:16 PM

You are replying to this message

"why couldn't Phoenix be designed to use the same extension mechanisms as Mozilla"

They do use the same mechanism. It's called XPI - cross platform install.

"What happens if K-Meleon comes along and says "we require our extensions to use this format"? Then Galeon says the same thing. "

Um, they have. They explicitely DON'T support any XUL extensions. They are native frontend projects that don't use XUL at all. Not one bit of XUL. I doubt they even support XUL in content (although I might be wrong). You certainly can't install any Phoenix extension into Galeon or K-Meleon that I know of and I've certainly not heard of anyone making a K-Meleon extension work in Mozilla or Phoenix. They are all completely different formats (for one thing, Kmeleon and Galeon have native code frontends just like IE so they're "totally different and unrealted applications" when it comes to frontend extensions). I doubt that any of the "not quite frontend" extensions are interoperable either. Kmeleon and Galeon don't even support the install mechanism for extensions like mouse gestures.

"Suddenly it become such a pain that people say it's not worth it"

Suddenly!!!??? What do you mean suddenly. There has never been any frontend extension that worked in Galeon and Kmeleon or in Mozilla and either of those native frontend apps. There's nothing new here. They're as incompatable with XUL extensions as IE is.

"hoenix and Mozilla codebases are very largely the same, you admit the modifications are few, why couldn't Phoenix be designed to use the same extension mechanisms as Mozilla?"

Phoenix shares a majority of code with Mozilla, that's for sure. It's probably like 95% or more. The problem is that the 5% it doesn't share is the very same 5% that extensions hook into. As far as extensions go, Phoenix is a different app and it's going to get more and more different as Phoenix cleans up more and more of the UI. That some of the extensions sort of work in Phoenix now is because there are still some Mozilla front end files, similarly named files or similar XUL structure in Phonix but that's changing.

What do you suppose a Phoenix extension that installs itself into the customize palette should do when someone tries to install it in Mozilla where no such palette exists? What about a Mozilla extension that tries to install itself into the Windows menu which doesn't exist in Phoenix. The UIs are diverging and so UI extensions that install themselves into pieces of UI which don't exist in the other application can't be expected to work.

The extension authors can probably make the extension smart enough to use an alternate install target ID or something based on which app they're being installed into but I don't think that Phoenix (or Mozilla, for that matter) should carry the weight (usability, performance and size hits) of all of the chrome of the other app just so that all of the extensions will have the same install target on Mozilla and Phoenix.

The architecture is similar so it shouldn't be hard to port extensions between the two apps. Maybe someone can even write a little script that maps locations from one app to the other which could be run on an extension modifying it to work well on the other app. Something like that might help but in the end, Mozilla and Phoenix are different apps with different UIs so UI extensions are going to need to get smarter or they're going to have to make one for Phoenix and one for Mozilla or they're going to exclude one.