Mozilla Looking to Forge Alliances with GNOME and Other Open Source Projects to Combat Longhorn
Tuesday April 6th, 2004
jgraham writes: "Brendan Eich has written an interesting post to the netscape.public.mozilla.seamonkey newsgroup outlining some of the plans being made to ensure that Mozilla technology remains useful and relevant in the future. Brendan sees Mozilla developing into an open cross-platform alternative to forthcoming Microsoft technologies such as XAML and is looking to collaborate with other open-source projects to make this happen." The GNOME project is mentioned explicitly. Brendan's message is part of a longer thread about the goals of mozilla.org.
Wow, this is big. I'm glad to see Mozilla developers thinking this far ahead. There are a few years before Longhorn comes out and gets widely adopted, and if this plan succeeds, I think we could give it some good competition. Not being a real developer, there is something I have a few questions about: in (IV), it says "build a new, unified desktop/web application platform from pieces of Mozilla and GNOME code, starting now." Would this still involve a GRE? What parts of the Mozilla source and GNOME source code would be used? How would the Mozilla and GNOME parts communicate and interoperate? Would there have to be major rewrites/revisions of code? And why GNOME and not KDE - because of the license, the architecture, or the willingness to work with us?
I think the reasons for Gnome are simple: 1) Gnome is supported by major Linux/UNIX companies (Novell/Ximian, Red Hat, IBM and Sun Microsystems) and is the de facto standard for corporate Linux users. 2) Mono has a Gtk/Gnome integration (gtk# etc.), there's no such thing for KDE. If the new Mozilla-based platform wants to use .NET languages (C# and friends) with XUL on Linux, Mono is the only reasonable choice. 3) Mozilla uses the same set of libraries as Gnome (gtk), while KDE uses qt. The Mozilla/qt port is dead, nobody was really interested in maintaing it. 4) Major Linux applications (both free software apps like The GIMP and proprietary like VM Ware) are GTK-based. 5) Gnome is less bloated than KDE. 6) KDE already has Konqueror, they rather wouldn't like to trash it... :)
Mono is so good to Microsoft ... that they collaborate giving information to Mono programmers. Also, Gnome has a windows-like registry (all the messed shit goes there).
So those are good reasons
You're wrong. Gnome DOES NOT have a Windows-like registry. Gnome's configuration is held in a bunch of XML files. GConf-Editor looks similar to regedit.exe, but only the GUI is similar.
I also disagree with your opinion about Mono.
You're wrong. Gnome does have a Windows-like registry (though not exactly). <http://www.google.com/sea…ch?q=%22gnome+registry%22> <http://www.google.com/sea….org+%22gnome+registry%22> (I am not going to search for more, work to do)
I also disagree with your opinion about Mono. Miguel has said many times he has been helped (been given information, for example) by Microsoft people... guess why... (hint, hint!: Microsoft wasn't forced, so Mono beneficiates .NET and M$)
I also disagree with your opinion about Gnome beeing less bloated than KDE.
... but after all, I think marcoos is not an enemy, but sort of an ally.
> Gnome does have a Windows-like registry (though not exactly).
So either it does or it doesn't. All the google links put 'registry' in quotation marks because although they're using a familiar term it doesn't quite apply. I mean you could call prefs.js a 'registry' because it holds configuration data which is organised into a tree-like structure (though not in the file itself) and may contain data from multiple installed applications.
Conclusion: argue based on technical specifics rather than based on the use of taboo words.
However this isn't the place for Gnome v KDE flamewars. If Mozilla people can work with Gnome people to create something that s better then either Mozilla or Gnome s today then that's A Good Thing and will probably be useful regardless of which (if either!) desktop environment you prefer.
> So either it does or it doesn't. We don't live in a black or white world. It is not "it is black or it isn't". There is gray.
> All the google links put No. All no.
Conclusion: Two first sentences and two errors. Not good. Better luck next time.
> However this isn't the place for Gnome v KDE flamewars. Though you didn't tell this to the comment #10 (you know why), you are right
> If Mozilla people can work with Gnome people to create something that s better then either Mozilla or Gnome s today then > that's A Good Thing You are right again
> and will probably be useful regardless of which (if either!) desktop environment you prefer. And you are right again, too
(Carriage returns and Mozillazine. Another post is needed)
> So either it does or it doesn't.
We don't live in a black or white world. It is not "it is black or it isn't". There is gray.
> All the google links put No.
Conclusion: Two first sentences and two errors. Not good. Better luck next time.
> However this isn't the place for Gnome v KDE flamewars.
Though you didn't tell this to the comment #10 (you know why), you are right
> If Mozilla people can work with Gnome people to create something that s better then either Mozilla or Gnome s today then
> that's A Good Thing
You are right again
> and will probably be useful regardless of which (if either!) desktop environment you prefer.
And you are right again, too
> We don't live in a black or white world. It is not "it is black or it isn't". There is gray.
Which is why you have too discuss things in technical terms wiithout making broad statements that don't allow for shades of grey. The correct question is not 'does Gnome have a (windows-style) registry?' but 'does the Gnome config system have any of the problems the windows registry has and where were the tradeoffs in the design?'. I don't know the answer to the second question but I do know the first question is useless.
>> All the google links put No.
That's not what I said. But it doesn't really matter
> Though you didn't tell this to the comment #10 (you know why)
I thought about it but decided not to post before there had been any responses. I hoped everyone would let it go :-)
Anyway the point is this: what does Mozilla stand to gain from better integration with other open-source products and what do people stand too gain with Mozilla-like technology on their desktop? The answer, I hope, is 'a lot'.
> The correct question is not 'does Gnome have a (windows-style) registry?' but 'does the Gnome config system have any of the problems the windows registry has and where were the tradeoffs in the design?'.
The word 'registry' on its own simply means 'a centralised place to store data in a consistent and organised fashion'. With such a broad definition, implementations can take all forms of shapes and sizes, ranging from a simple text file (e.g. prefs.js in Mozilla) to a full-blown binary database (like Windows). The GNOME gconf system lies somewhere in between. It is a set of XML files (i.e. they are in plain text and can be read/modified in a text editor), organised hierarchically on the file system. It is very flexible, and it does NOT suffer from many of the weaknesses of the Windows Registry.
Thanks for the answer. Perhaps one effect of this new initiative, if it goes through, is that more people may standardize on GNOME, which would lessen the fragmentation within Linux. Another point to make is that this major new initiative may help the Mozilla Foundation get more funding from companies that have an interest in seeing Linux succeed or don't like the MS monopoly.
1) So does KDE (Novell/SuSE, Mandrake, Lindows...) and has more market share among desktops. 2) Yes, but it can have KDE integration, Qt#. 3) True 4) There are also perfect Qt apps 5) That's your personal opinion. Technically, Gnome is much more bloated than KDE. KDE is a lot more itegrated and organized (kparts, DCOP, kio...) 6) And Gnome has Epiphany, that although it is a Gecko-based browser, isn't Mozilla.
I found reasonable starting with Gnome, but I think that it also will be good -perhaps not just know- to put in contact with KDE people about XUL in KDE and all that. This way, we would be stronger to battle Longhorn... There have always been flame wars between KDE and Gnome, but with Microsoft as an "enemy", I think they are more allies than enemies.
lets say Gnome 3.0 will be completly XUL based....
This is an interesting idea. If Gnome and Mozilla get integrated with each other, then we maybe could customize our desktop kind of like a webpage. And perhaps there could even be desktop extension xpi's to add in new features. Imagine all the power of bookmarklets and other Mozilla tools on your desktop, and as easy to customize as editing text files.
While we're on the topic of the desktop, I'm sure Sun's Project Looking Glass (<http://wwws.sun.com/software/looking_glass/>) will catch on in the coming years. Check out the demo or screenshots if you haven't seen it yet. It's a 3D desktop!
Odd how that sounds just like what people were saying when microsoft integrated IE4 into windows 98..
The obvious difference being that if you use linux you aren't forced to use mozilla.
>>The obvious difference being that if you use linux you aren't forced to use mozilla.
Never has anyone been forced to use IE on Windows. You could always use whatever browser you wanted.
You cannot start the windows operating system without loading Internet Explorer into memory. At least not without serious modification. Please correct me if I'm wrong but that was the entire basis of the anti-trust cases filed against Microsoft.
Of course youz can. There are tools to completely (!!) remove IE. WinXP Embedded has IE as an optional component.
In WinXP, even the Luna theme uses IE. Your loading the HTML rendering engine, though, not IE the front end.
You are ignorant. Windows (any version) has *never ever* loaded Internet Explorer into memory. Some versions loaded the rendering engine for displaying various things on the desktop and folders. In Win9x you can turn even this off by turning off the active desktop. There is absolutely nothing wrong with that. Many OSes do that nowadays.
Open the file explorer, type <http://www.google.com>
>>Open the file explorer, type <<http://www.google.com>>
You are not a developer, are you?
Just FYI, you can load widgets, rendering engines and the like on demand in Windows (and other OSes probably too). The explorer app simply detects that a URL is being requested and loads the IE rendering engine.
#3 I agree with our plan.
by pkb351 <email@example.com>
Tuesday April 6th, 2004 10:06 PM
I believe that recent events agree with your assessment of the directon MS is diving Longhorn. The recent European Unipon Antitrust Trial was not really about MediaPlayer IMHO. This trial was about how Microsoft leverages its OS by bolting in proprietary technologies to its Windows code. The trial actually was about Longhorn and setting up a way to prevent MS from leveraging Longhorn to limit competition. The EU ruled that MS must "unbolt" Media Player hopefully will make future "bolting" cases easier and quicker to rule on (a Longhorn search bar comes to mind). The direction I see the EU moving (and I hope it works) is to set up a ruling that prohibits MS to use Longhorn to promote propritary standards whose sole purpose is to lock out competing OSes and other software vendors (ie Linux in the server market). The EU ruling I believe makes it much harder for MS to lock out (through poor interoperability) servers running non-Windows OSes. I understand this trial as an attempt to say to MS you are not allowed to add propritarty standards or non-removable programs to Longhorn if the reason is to limit competition. Lets hope the EU gets it right.
The EU is addressing a very similar issue being faced by Mozilla. How can open standards be protected? For Mozilla to be part of the solution Mozilla and its software technologies have to gain market share. We cannot sit back andwait for the EU to reign MS in or to restore open standards for us. At the moment there are several companies very dependent on standards remaining open (Apple, Linux vendors, Sun, IBM, just to name a few). Could Mozilla partner with some of the larger companies?
<an aside>I believe Apple missed the boat when it bypassed Mozilla for Safari. Apple is one company that could be hurt the most if the propritary standards of Longhorn catch on and would have a lot to gain if they embraced to crossplatform application building nature of Mozilla.I going with Safari I believe Apple was tired depending on outsiders for their web browser. Once burned, twice shy. My hope is that once Apple sees and understands the importance of the crossplatform open standard nature of Mozilla they will at least support, if not embrace, Mozilla.</an aside>
I beleive we are already late in putting Brendan's plan into action. MS has a good marketing department. They are already promoting and evangelizing the propritary technolgies, even though they are at least a year away. I believe Mozilla has to also do its marketing and evangelism. (I only wish we had a budget and large staff to carry this out.) For Brendan's strategy to work, we have to inform conmpanies, develpers, and others of these goals for Mozilla as not just a browser, but a platform. When the plan has been developed into its final form, could this vision be given a very prominate palce on the Mozilla.org web site. Could a press release be sent out to the releveant News sites/Magazines (tech and bussiness mags.)?
I think Brendan is on the correct path. We have to provide a reason for people to use Mozilla and its open standards. If we fail to provide a compelling reason, then many will simply default to the propritary MS/Windows offering effectively shutting out most non-Windows solutions. <an aside>Boy do I wish that judge had been able to break MS up.</an aside>
#43 Don't discount Apple users in this...
Wednesday April 7th, 2004 12:01 PM
>> I think Brendan is on the correct path. We have to provide a reason for people to use Mozilla and its open standards.
I use MS and Sun at my day job and Mac OSX at home. On both MS and OSX platforms I use Mozilla Thunderbird for email because it is straight forward to use, has a simple, clean interface, has all the features I need, and does a great job of flagging spam. On Mac OSX for email I've tried Entourage and the native Mail app. My point is that if Mozilla provides a compelling solution on any given platform then people will use it. Please don't dismiss Mac OSX in your plans.
As far as Safari goes, Apple users switched in droves because we all knew that *finally* we would have a fully supported web browser that was native to the platform and understood what Apple users wanted. That's not a dig at any other browser, that is just the need that users had and Safari solved that beautifully.
If Safari were to integrate an open standard promoted by Mozilla of some sort of User Interface Markup language then any apps developed that way could hopefully also run in Safari. In that case it would not require users to adopt Mozilla as their browser but simply make use of Open Source apps written in a markup language. (saying that all user interface markup languages are the same seems pointless to me. a language will either work with a browser or it won't)
Open Standards are important. Apple users understand all too well the unfortunate skill that they must develop in dealing with websites in particular that have decided to alter their webpages using a proprietary coding method that is only functional with one company's products. (Not much fun when it locks you out of your online bank for instance.)
This is an important initiative. I'm not a developer just a user of Mozilla Apps. One thing I'd like to stress, don't let the technical implementation and organizational politics get in the way of making a compelling, open source, standards based, and usefull tool.
> looking to collaborate with other open-source projects to make this happen.
Well, if I dare to say if Mozilla.org and Brendan Eich is serious about working together with other open-source projects. Why not join the Open XUL Alliance? See <http://xul.sourceforge.net> for details.
First of all Gerald, how about you use an acronym besides XUL for your website. It's confusing to everybody and more of a headache than it's worth. Then Mozilla can join your "Alliance". I think you would find yourself with a lot of supporters from the Mozilla camp if you just caved and agreed to help _us_ out too.
Why you haven't just agreed to work with us is a mystery to me. I recall reading the photoshop support newsgroup. A fellow (Timo Autiokari) has been posting there for years, and his recommendations towards users are perpetually based on fundamental misunderstandings of graphics editing. They tell him to stop, but he refuses to listen. (You can see his website at <http://www.aim-dtp.net>, but don't believe a word of it. Search google groups for the truth.)
Extreme stubbornness is an interesting thing to analyze. I wonder if Gerald hopes to spearhead some sort of XUL revolution. First, he dilutes the name. Then, as XML-based graphical interfaces take off, he gets more traffic. Since he's the primary dilutor, he gets the credit for the pheonomenon.
As a last point, it should be clear that XUL is already open, and furthermore, that joining the "Open XUL Alliance" does not change that. It's much more significant that Mozilla is working with a standards body to get a spec out for XUL. See Hixie's natural log (blog).
> It's confusing to everybody and more of a headache than it's worth.
Well, XUL/XUI/XAML/UML/WML/etc. it's all the same. Whatever acronym you pick someone will always complain. Please get over it. The debate is over and the world has moved on. I have spent more than my fair share to listen to your silly arguments. See <http://xul.sourceforge.ne…nguage_trademarkable.html> for example or browse the xul-talk mailinglist archives online @ <//firstname.lastname@example.org>" rel="nofollow"><http://www.mail-archive.c…<email@example.com>>
> Then Mozilla can join your "Alliance".
Well, isn't it ironic that a dozen project leads take part in the XUL Grand Coding Challenge 2004 but Mozilla is missing? Who is the loner here if I dare to say. See <http://xul.sourceforge.ne…invitation_last_call.html> for details.
> It's much more significant that Mozilla is working with a standards body to get a spec out for XUL. See Hixie's natural log (blog).
You seem to be new to the XUL discussion. Please read up on what Hixie has said about XUL, Mozilla and standards on the xul-talk mailinglist. Also note that Mozilla has no interest in working with standards body to get a spec out for XUL. Nor has the W3C any interest for obvious reasons. Also note that before you hand a spec over to a standards body wouldn't it make sense to drum up support from other browser vendors or projects? Do you truly believe you will get any buy-in from Microsoft, Apple or Sun for example? Also if you haven't noticed it the point of open standards is to avoid vendor lock-in and offer choice. If XUL were a W3C standard, how could it be a Mozilla-only trademark? Please explain. Also note that Hixie himself works on a new spec that will compete with Mozilla XUL. Look for Web Application Markup Language.
Finally, what about W3C XForms? Why is Mozilla ignoring the W3C recommendation/standard for web forms? Can you explain.
#32 Re: The XUL Naming Debate Is Over
Wednesday April 7th, 2004 10:43 AM
<i>Well, XUL/XUI/XAML/UML/WML/etc. it's all the same. Whatever acronym you pick someone will always complain.</i> Actually, XUIL isn't taken. Search google for it. Fewer than 400 mentions on the whole web. I don't think you'd get any complaints. But that's not your agenda, is it?
It even sounds cool. Zoyle. Unfortunately, "XUIL" is not going to match a google search for "XUL".
<i>Well, isn't it ironic that a dozen project leads take part in the XUL Grand Coding Challenge 2004 but Mozilla is missing?</i> Being that there are so many great applications already written in XUL, I think that Mozilla's absence says less about Mozilla and more about the XUL Grand Coding Challenge. But you know that. You create these "important" "XUL" "events" so that you can become a host for some "revolution". Because what we really need is a coding challenge, right?
Consider that even if the standard is controlled by Mozilla, its reference implementation operates under the tri-license, which allows easy code reuse. Anyone who seeks to reimplement XUL, whether the spec is controlled by Mozilla or not, can easily look at the source code. That makes Mozilla's position with respect to XUL different from, say, Netscape or Microsoft with respect to HTML. The extensions Netscape and Microsoft made to HTML had to be reverse-engineered: open spec, closed implementation. Any extension Mozilla makes to XUL will be completely transparent, with the source code at any reimplementor's fingertips.
As for XForms, I didn't know much about the issue, so I fired up Bugxula. (A useful app written in XUL. Joy!) Don't listen to Gerald, just check bug 97806. It reveals that Mozilla developers are wary of the XForms spec (just because it's W3C doesn't make it good, just because it's a standard doesn't mean it must be supported), but would be very much willing to consider including XForms support if someone steps up to develop it. They make no promises, but for the moment would at least support XForms as an extension.
You would have a real gripe about XForms support if Mozilla had actually rejected some hard code. Why don't you implement it for Mozilla, and then see what happens?
I agree with you on all points. If Gerald has been this stubborn simply about a name, imagine what it would be like to work with him. If and when the time comes to make a new XUL 2.0, and he or others offer some polite, constructive suggestions on how to make it better, that's great. Otherwise I'd wish he stop bothering us. Besides, if there is reason for any of these other XML UI projects to work with us, I'd rather deal with them directly than through Gerald and his Alliance.
I wonder, if trademark infringement is in order, and this person is being such a continuous nuisance, why not let some of the Mozilla Foundation's lawyers take care of it?
IANAL, but US law requires people to defend their trademark or they risk losing it. I am not sure if that means just telling him to stop (which has been done) or taking legal action. I suppose the Mozilla Foundation so far has just had a lot of more important things to do than the latter.
#84 Thank you and a question about color
Thursday April 8th, 2004 11:20 PM
Adam or Asacarny wrote:
>A fellow (Timo Autiokari) has been posting there for years, and his >recommendations towards users are perpetually based on fundamental >misunderstandings of graphics editing. They tell him to stop, but he refuses >to listen. (You can see his website at <http://www.aim-dtp.net>, but don't >believe a word of it. Search google groups for the truth.)
Thank you very much for the advertizement! (Got the all time highest score in the logs). Surely people can decide what they believe on their own, rather than taking the word of an anonymous poster.
Where do you discuss about ICC color-management? It would be very nice if Mozilla could soon be ICC compliant! I believe this would only require something like 10 rows of code, please do it and be the first (on the Windows side).
geraldb goes on and on asking for why he cannot use the term "XUL" for things that aren't XUL. <http://sourceforge.net/ma…718347&forum_id=32541> took place in January and Hixie quite clearly showed how geraldb fails to justify his usage of "XUL".
Funny is that almost exactly the same sequence of forum posts happened half a year before: <http://sourceforge.net/ma…essage.php?msg_id=5148075> geraldb had made up a different example, but already there his reasoning was shown to be wrong.
Who wants to bet that geraldb will not have new examples and again be rebutted? This annoing guy wants to exploit Mozilla's fame to get famous himself. Fine, geraldb, so after mangelo you are the next famous pain in the ... of everybody working hard to make Mozilla a success. Well done, but you will vanish as mangelo (virtually) did. And there will be others...
> Well, XUL/XUI/XAML/UML/WML/etc. it's all the same. Whatever acronym you pick > someone will always complain. Please get over it. The debate is over and the world > has moved on.
I cannot say for sure about W3C standard and such, but to say XUL and XAML are the same, that I am quite sure is confusing. Nor will I see Microsoft will agree with your definition. Microsoft is not about to subscribe to any but its own controlled standard anyway.
#8 XAML is Just A Code Name It's Not A Trademark
Wednesday April 7th, 2004 1:01 AM
> but to say XUL and XAML are the same, that I am quite sure is confusing.
Not at all. Just look at some XUL/XAML/XUI/etc. markup and you will see that it's all the same. If you want to brand your browser/player/runtime you need to use a proper name e.g. Mozilla. Luxor, Ibex, Laszlo, Flash, Java, etc. See the pattern?
> Nor will I see Microsoft will agree with your definition. Microsoft is not about to subscribe to any but its own controlled standard > anyway.
Please not that XAML is just a code name. It's not a Microsoft trademark. Microsoft will unveil a new name once Longhorn (Windows 2009) goes live (e.g. Windows (TM) Markup Language - WinML - or similar). Why not follow the Microsoft lead an use a proper name such as Mozilla (TM) Markup Language - MozML or MML or M2L or similar? Also note that XAML initally stood for eXtensible Avalon Markup Language and now stands for eXtensible Application Markup Language or XML Application Markup Language and is a generic term like XML UI Language (XUL).
For example, check out the MyXAML project online @ <http://www.myxaml.com> It's not a Microsoft XAML clone but MyXAML uses it's own markup. What do you say now?
#11 Re: XAML is Just A Code Name It's Not A Trademark
Wednesday April 7th, 2004 1:22 AM
Dude, you are basically repeating what you said. You can repeat what you say to yourself.
No, Microsoft is not going to make XAML like this "all the same" boat. Most people remember what happened to Java and Visual J++. Is it what you call it Java in Microsoft implementation? Why the Sun lawsuit get started?
It's not even about Trademark issue I am worrying about. What you are saying is almost equivalent to say all mark-up languages are the same, now how useful a statement is that is everybody's guess. In actual implementation, I do not believe any way to define all "XUL" are the same is any useful, not to Microsoft, in the least. Yeah, in another Halloween document I remember Microsoft has been trying to make XML Mark-up a standard, that everybody will use _their_ standard.
You can fight for your name-calling issue. But that's irrelevant to the actual competitive development picture, nor it can in anyway ensure compatibility between Microsoft XAML and any other XML User Interface languages out there, including Mozilla's XUL.
#17 Re: XAML is Just A Code Name It's Not A Trademark
Wednesday April 7th, 2004 2:31 AM
> Any comments? Yes. I noticed that for some reason, all those projects use another name. None of them is called xul. because the are no xul. Xul is what mozilla uses. The rest are random xml things that happen to create an ui, just like xul does. Why is the name XUL so special it is a genric term? I mean, it is not the most obvious abbrevation of Extended Markup Language User Interface Language. Anyway, why am I writing this? You are ignoring it anyway.
>>Why not follow the Microsoft lead an use a proper name such as Mozilla (TM) Markup Language - MozML or MML or M2L or similar?
Why? Because they have ALREADY given it a name, they called it "XUL". Next time I get some extra cash around, I'm donating to mozilla so they can sue your sorry ass!
#57 Re: XAML is Just A Code Name It's Not A Trademark
Wednesday April 7th, 2004 7:41 PM
> Please not that XAML is just a code name. It's not a Microsoft trademark. [...] Also note that XAML initally stood for eXtensible Avalon Markup Language and now stands for eXtensible Application Markup Language or XML Application Markup Language and is a generic term like XML UI Language (XUL).
... and all this time I thought "windows" was a generic term, too.
This sounds like a powerful vision. It will be a lot of work. Especially since the platform should also scale down to smart phones. I hope Mozilla will be able to leverage enough interest and manpower to pull this off.
Is this just the personal vision of Brendan or is the plan adopted by Mozilla itself?
Edd Dumbill's blog is particularly interesting in the context of establishing this Alliance:
#14 Mozilla can't go it alone - Are ready to open up?
Wednesday April 7th, 2004 1:57 AM
> Edd Dumbill's blog is particularly interesting in the context of establishing this Alliance:
Allow me to quote the core passage:
If we were to back [Mozilla] XUL for a next generation of GNOME UI, what would need to happen? First and foremost would be a political and social change to get more dialogue going between Mozilla and GNOME. Secondly, there'd need to be a way to ensure a good native GNOME look and feel and interoperability. Thirdly, it would need to be extensible enough to use the richer palette of widgets GNOME offers. Fourthly, Mozilla needs to get SVG support done to bring richer graphics into the UI.
I like [Mozilla] XUL, I really do. But I worry that the drag factor is too large to bring [Mozilla] XUL up to GNOME's level of expressivity, and GNOME doesn't want to throw away what it's got.
#44 Re: Mozilla can't go it alone - Are ready to open up?
Wednesday April 7th, 2004 12:09 PM
1) Political change: That's what this announcement is meant to put in motion. I believe people *want* to work together if it will help us write better software.
2) Native look and feel: Correct me if I'm wrong, but doesn't Gecko already use GTK+ to render on linux? Seeing as GTK+ is *GNOME's* own GUI engine I think your point here is moot.
3) Extensible: XBL allows you to bind pretty much any widget, native or non-native, to an XUL tag an make it all transparent to the end-developer. I can't see why you'd have any trouble implementing any additional widgets.
4) SVG: I agree with you somewhat on this point; however, Gecko does have some very robust SVG support in the works. There are even some recent SVG-enabled builds up in the forums.
Lastly, GNOME won't have to throw away everything it has so done far, it can and should continue to allow a more traditional style of GUI programming. What we can do is allow for a rapid-development environment where the GUI is separated from the "business logic" code.
Well, it's true that Mozilla developer documentation is hard to find.
Speaking of which, Nigel McFarlane's book: Rapid Application Development with Mozilla, is now available as PDF download from Bruce Peren's Open Source Series at InformIT's host homepage:
Hopefully more docs like his will be available so we can attract more XUL developers. Btw, please support the author and buy the book if you find it to be useful.
I don't have the money for even a cheap book, so it's nice to finally look at this thing. Ever since the author mentioned he was releasing it online, I've been waiting to download it. Perhaps when I'm not cash-strapped I can buy a copy, but for now this downloaded version is perfect. Thanks!
#15 KDE And Mozilla? Any News? Any Comments?
Wednesday April 7th, 2004 2:02 AM
does anyone know if anyone at Mozilla is interested in the KaXul & Uxul project lead by George Staikos that tries to bring Mozilla XUL to the KDE Linux Desktop without requiring the Gecko machinery. See <http://webcvs.kde.org/cgi…sweb.cgi/kdenonbeta/kaxul> for details.
#16 Flash and Mozilla? Any News? Any Comments?
Wednesday April 7th, 2004 2:04 AM
does anyone know if anyone at Mozilla is interested in the Zulu project lead by Ovi Comes that tries to bring Mozilla XUL to the Flash player without requring the Gecko machinery. See <http://zulu.netspedition.com> and <http://xul.sourceforge.ne…i_comes_of_zulu_fame.html> for details.
noone is interested and now leave mozillazine.org geraldb
#27 Please Grow Up; Learn To Accept Different Opinions
Wednesday April 7th, 2004 6:53 AM
> noone is interested and now leave mozillazine.org geraldb
mcsmurf, can you identify yourself. Whom do you speak for? Please learn to accept different view points.
#34 Re: Please Grow Up; Learn To Accept Different Opin
Wednesday April 7th, 2004 11:03 AM
He represents the majority of us! Now please, take you XUL crap somewhere else. (why not start your own forum?)
The worst part about it, is I think you "XUL Alliance" is an excelent idea, and I bet many many many Mozilla folks agree with me and *would* have joined your effort. The problem is, your dissrespect for other people's work.
#42 Re: Please Grow Up; Learn To Accept Different Opin
Wednesday April 7th, 2004 11:59 AM
You're not providing different view points. You're hijacking a thread to suit your purpose.
#56 Re: Please Grow Up; Learn To Accept Different Opin
by coolestuk <firstname.lastname@example.org>
Wednesday April 7th, 2004 7:38 PM
Gerald, when I first started to learn about XUL, I saw your name very prominently, and would visit your site and read what you have to say. As time has gone on, I have realised that you need medical attention.
Go and find yourself some other technology to destroy. You are manifestly unpopular, and you are not helping the cause of XUL.
I would avoid anything to do with you. Are you being paid by MS to cause diversions around Mozilla and XUL?
#25 Novell plays an important role
Wednesday April 7th, 2004 6:04 AM
Novell bought Ximian, but in a recent meeting with other major linux supporting companies, has agreed to develop on the QT toolkit. What can Novell do? What WILL Novell do?
#52 Re: Novell plays an important role
by brendan <email@example.com>
Wednesday April 7th, 2004 7:06 PM
The Qt news was misleading. See <http://slashdot.org/comme…mp;sid=102104&tid=189>.
There is one thing that alway concern me about the competition with LongHorn, Gnome, KDE, OS X, etc is that those XML codes would become incompactable with each other for the website and application interface. It is just a more headache for the programmer.
True, but if this works, you'll only have to program twice (XUL/XAML), as apposed to 5 or 6 different specs.
Well, better to have incompatible code, than code whose evolution and syntax is dictated by Microsoft (apparantly very badly, by the way, see the recent entry on the myxaml homepage). And better to have 2 major XML UI formats than 10.
Amen. Also, XUL will be cross-platform. So if you chose to write your app in XAML you'll be (presumably) locked into a MS Windows only product, but if you write your app using XUL it can be deployed on *any* platform, including MS Windows.
The other great thing about both XML-UI languages is that they should, in theory, scale *down* very well also. Imagine running the same apps on your cell phone that you run on your desktop. Cool beans, eh? ;)
> The other great thing about both XML-UI languages is that they should, in theory...
As an exercise, care to abbreviate XML UI language?
Add one letter, take away the confusion. Everyone wins.
If you mean create an acronym (form from the initial letters of other words), then XML-UIL would appear to be what you are looking for.
If you truly mean abbreviate, then you could shorten something in a whole heap of ways. One of those ways (XUL) was used by the mozilla developers to name their particular user interface language. Being imaginative, they made this name up all by themselves. Once the name was chosen, they wrote code to handle the XUL syntax, made sure files containing such syntax ended in .xul, and wrote documentation on the XUL syntax. (I also think they discussed making the XUL syntax a w3c ratified spec, but I'm not sure where this went.) In short time, it was well-established that "XUL" was the name of the syntax used by mozilla developers to describe user interfaces. That is, XUL meant the XUL syntax.
Then you decided the term "XUL" was a good name to refer to *any possible* user interface language. And it is, too. But the term "XUL" already had a well-defined meaning; it can't refer to *any possible* XML-UIL and a *particular* XML-UIL at the same time. Thus, there are 3 possibilities: the mozilla developers rename the XUL syntax (new filename extensions, new documentation, new website names, etc.); you use a different name for XML-UILs; or we allow confusion to prosper (e.g. "No, no. I don't mean any XUL. I mean Mozilla's XUL. You know, XUL XUL. There's a difference.")
Names are arbitrary; you could call XML-UILs 'interlingos' or even 'babchicks'. But a well-chosen name is 1) mnemonic, 2) well-defined and 3) unique. Presumably you jumped on XUL because it satisfies (1), not caring that it violated (2) and did not satisfy (3). However, there are plenty of candidates that satisfy all three properties: XUI, XIL, UIL, UL, XUIL, XWL (widgets), XFL (forms), XInterface, XFace, XFront, etc. One just needs an imagination.
What makes your behaviour so disappointing is that Mozilla hasn't the ability to protect the name it chose - further reason to trademarking everything.
#64 XML-UI is trademark, please stop using it now
Thursday April 8th, 2004 12:37 AM
Maybe it helps to see how silly it is to trademark generic terms if we pretend someone claims that XML-UI is a trademark.
> The other great thing about both XML-UI languages is...
Please stop using XML-UI now and find yourself a better term. How about XML-UIT or X-UI or XUI or XMLUI?
#72 Re: XML-UI is trademark, please stop using it now
Thursday April 8th, 2004 7:51 AM
Dude, I specifically chose to use "XML-UI" as a generic term to refer to *both* major xml-based user interface description languages as well as whichever minor projects I'm not familiar with.
To refer to Microsoft's XAML product as "XUL" is an insult to all the hard work going into the Mozilla platform. "XUL" is a well known term which is already in common use among the Mozilla community. I fully support the creation of other implementations of the idea of an xml-based user interface, but unless a project is going to render actual (Mozilla) XUL it should come up with another name for its markup language.
I'm very sorry that you're having such a hard time with your alliance here, but you're not being very cooperative with the rest of the community.
#47 Nooo! (disconnected rants)
Wednesday April 7th, 2004 12:55 PM
Mozilla + C# Gnome= worst of both worlds, overengineering to the max, "hello world" requiring 1GB of libraries, fancy effects at the expense of basic functionality, every library wrapping every other one, API definitions larger than the Library of Congress, and user hostility touted as user friendliness (even in current Gnome versions, a prevailing message to users who want to do more than "launch The Internet" but don't write new RPC protocols for fun or XML parsers in their sleep is "I'm sorry Dave, I'm afraid I can't let you do that").
What's seen in the sweeping "mozilla the platform" vision seems to me to be a mirage. Wasn't the roadmap shift last year all about realizing that people are interested in a slim browser and rendering library, not an overambitious try at a fully buzzword-compliant comprehensive development platform?
I was once a Gnome fan, but I've been disappointed with Gnome because their strategy for some time - conjuring up frameworks of frameworks of frameworks and tilting at usability windmills- has alienated developers and users alike, and the only reason they're surviving is because of the influence and power the conjurers-up of its ground-up architectonic hold in the linux community and the pervasive illusion that this process amounts to increasing "enterprise readiness". This is not a stable situation.
Instead of trying to out-Microsoft Microsoft, trying to counter their vision with an equivalent one, why not provide a better alternative vision with simplicity and power?
"What's seen in the sweeping 'mozilla the platform' vision seems to me to be a mirage. Wasn't the roadmap shift last year all about realizing that people are interested in a slim browser and rendering library, not an overambitious try at a fully buzzword-compliant comprehensive development platform?"
While it is true that the "slim browser and rendering library" is a major focus of the Mozilla project now, I think the Mozilla project is still committed to developing a platform, because, as Brendan says in the newsgroup posting:
"If we do only 'the browser thing' ... we are likely to be irrelevant in approximately five years. Not unused, but trailing-edge..."
People obviously are interested in having a slim browser. That's why Firefox has been such a big deal. But there are also a lot of other people who are interested in more. Things like ActiveState Komodo started because people thought Mozilla was a good platform to build on.
I know what you mean about "frameworks of frameworks of frameworks". I think the same thing when I look at some of IBM's AlphaWorks technologies - Sash, for example. A little extraneous. But Mozilla has some good ideas that can't just be an aim at being "fully buzzword-compliant." Some of the Mozilla community's projects aren't trying to counter Microsoft's ideas - they're going further.
From Brendan's post, it looks like the GRE idea will still be carried out for Windows, etc. Since GRE will probably shrink the amount of space and the amount of files that multiple Mozilla programs will take up, it'll be a step in the "simplicity and power" direction.
...Some more disconnected thoughts for everyone to digest. :)
- Minh Nguyen <http://mxn.f2o.org/>
#54 Re: Nooo! (disconnected rants)
Wednesday April 7th, 2004 7:29 PM
Finally, a sane voice! For all the those "yeah, let's integrate everything into everything and crush MS..." folks, why stop at integration with Mono and Gnome? Full speed ahead and let's build a space station on the 3 moon of Jupiter and integrate that with Mozilla.
Stick to what you know and what you've been successful at -- and that's creating a slim-down browser and other components (i.e. thunderbird).
#55 Re: Nooo! (disconnected rants)
by brendan <firstname.lastname@example.org>
Wednesday April 7th, 2004 7:38 PM
Minh Nguyen has responded well already. I wanted to add: rest assured we are not looking to obfuscate or add extra layers, except where they demonstrably do not affect performance and actually simply programmer models. We can't afford to make things thicker or more complex; competitive pressure from Longhorn will see to that. When you're up against System.Windows.*, nsIFoo and gtk_ mixed together can't compete. We will need to present a unified, extensible class/object model of some sort, without reinventing Longhorn. That's a given.
And yeah, we have to walk and chew bubblegum at the same time: we must continue the FIrefox and Thunderbird work initiated with last year's roadmap, even as we jack up Gecko and slide in a new widget/graphics/extension-language platform.
#65 Re: Re: Nooo! (disconnected rants)
Thursday April 8th, 2004 12:43 AM
If it's followed through, this seems to me the most important turning point in Moz's history since it became open source. Actually, it's probably more important than that.
Does this mean there would be "new" binary code for widgets, rendering and file-system, and a new language that is some hybrid iteration of XUL/XBL/XTF/CSS/SVG/JS that allows "text-file" programs to access those binary code widgets, rendering and file-system tools? Would this mean development would take place alongside current mozilla development and would then supersede it (a bit like nglayout and mozclassic)?
How will you decide who works on it (within the MozFoundation, anyway)? Could you start coding straight away, or do you have to design the languages and widget/rendering/file-system architecture first? How would integrating more closely with gnome, while still being platform independent, work?
Sorry for so many questions, but my mind is overwhelmed by the potential here (for both possibilities and risks).
#50 I wonder when coherence...
by PrimalDK <email@example.com>
Wednesday April 7th, 2004 4:57 PM
...will enter the minds of the OO Revolution.
Don't get me wrong: You are all intelligent people, and you probably care deeply about these issues.
But you will never, ever keep up with the COHERENT effort of the thousands of people working ONE product.
This is why Microsoft is such a strong force. The diversity is our strength and our weakness.
Strength if diversity is what we want.
And this we want if we wish for a niche-role. And NO, Apple is not an example to the contrary. They exist only because of their COHERENCE. They are a niche-player because of Microsoft. A superior product doesn't make a winning concept in-and-of itself. This we learn from the Be/BeOS story. Now THERE's a desktop OS that beats my 3000MHz P4 XPensive Winbox hands down on my 200MHz, 604e-based Mac-clone.
Weakness if we wish to compete in the market of the public.
I had the typical experience this afternoon: With a GUI it took me all of 10+ minutes to complete something that later took me less than a minute in a shell. The opposite sometimes holds true too, but in the eye of the public, the PERCEIVED value of a GUI is an order of magnitude higher than that of a shell, mainly because the public isn't BASH-ing away 8-10 hours a day for years on end. What you do not understand, you fear.
If there was ONE command - ls or dir, I don't care (well, ok, I do), ONE desktop, the best or not, then the public would feel SAFE/SECURE because of the COHERENCY of what they were trying to interface with, and that again is the permeating argument PRO Windows: "It's Windows, it's always been Windows, it's backwards compatible, it's a gradual change with Windows, it's not a shift of paradigms with Windows, it runs my programs, does Windows". This is not entirely true, but it's what the public perceives, and I believe this perception of COHERENCE => SAFETY/SECURITY to be at the root of Window's success, notwithstanding monopoly games and the like. People are lazy buggers, and they are scared to the bones.
So, if we want to succeed, we should CHOOSE for them. Who else should know? We are the experts, they aren't.
And I agree with the author: We should choose NOW.
[quote]This is not entirely true, but it's what the public perceives, and I believe this perception of COHERENCE => SAFETY/SECURITY to be at the root of Window's success, notwithstanding monopoly games and the like. People are lazy buggers, and they are scared to the bones.[/quote]
Just wanted to say that the above is a very good description of what I also think is the real root of Microsoft's success. They know this quite well and make use of it at every turn. Having an integrated Mozilla/*nix/User Interface/XML based/development platform is all well and good, it's a good plan, but unless Joe and Jane Public can sit down at the local Starbucks and use the resulting whatever-ma-callit then this alliance will be dead in the water.
#63 The Free Desktop is coming...
Thursday April 8th, 2004 12:36 AM
Ximian's Robert Love explains how Project Utopia will benefit the Linux desktop. <http://primates.ximian.co…blog/archives/000395.html>
Mozilla and the potential for interaction - <http://www.oreillynet.com/pub/wlg/4654>
Free software and good user interfaces - <http://ometer.com/free-software-ui.html> Free software maintenance: Adding Features - <http://ometer.com/features.html> Working on Free Software - <http://ometer.com/hacking.html>
Mozilla & XUL Technologies have an opportunity to to participate & possible dominate the 'look & feel' of these Apps & UI's for years to come. Does this scare you? Then, stop bickering and ask "What can I do?" to help make a Xplatform Free Desktop available to the masses. IMHO, this is _not_ about Gnome canabalizing Mozilla, but a logical evolution for Mozilla to become a Core Technology on the way to a Freedesktop. -Life/Love/Laughter
The reason I chose gecko is because it is a platform to build on that is not affected by different operating systems :) so we can therefore build plugins to make it work on JDS, Gentoo (I use JDS on my laptop and Gentoo on my desktop) and any other *nix, windows based system out there :)
So yeah I am sure you can see why I agree with Brendan Eich!
#69 Re: I agree with this 100%
Thursday April 8th, 2004 4:57 AM
Something I forgot to add! If I am to embed python into my application, I will return all my code to mozilla who will hopefully merge it into mozilla itself, so we can compete with the use of using vb script in the browser for example:
<script language="pythonscript"> ... </script>
This would definatly be a nice feature to have built into mozilla :) as we can make even more powerfull programs using XUL. :-D
#70 Re: Re: I agree with this 100%
Thursday April 8th, 2004 6:22 AM
I assume you are aware of the existtence of pyxpcom which allows the creation of XPCOM components in python?
What would be fantastic is a way to use python more generally in the Mozilla framework e.g. for scripting XUL. AFAIK, pyxpcom doesn't allow for this. I think Brendan mentioned this at the recent developer day, so it would be great if you could contribute code to make it happen :)
#71 Re: Re: Re: I agree with this 100%
Thursday April 8th, 2004 7:00 AM
What I am attempted barely even scratches the surface of what *can* be done with the huge mozilla framework if wrapped to into a nice easy API (and made totally language independant -> all you would need is a compiler to convert it to the necessary byte codes, as well as the ability to link it to *native* applications) to rival both Java and .NET!
#74 Re: Re: I agree with this 100%
Thursday April 8th, 2004 8:49 AM
I'm just getting started with Python and loving it. I've done a little bit of Mozilla extension programming before (<http://weather.mozdev.org>) and I really think this would be great.
I assume you've spoken with some of the Python developers about this, yeah? I would think the security side of things would probably need a little work (Especially if you're going to let people embed Python code in a web page) but otherwise it should definitely be possible.
#106 Re: Re: Re: I agree with this 100%
Monday April 12th, 2004 11:05 AM
Actually no, I have not spoken to python developers, the idea of using python script within a website on the client side could turn out to be very secure, the idea is not to use 100% python API's, we would make python use Mozilla's api, its not something that we would just let run out there in the wild, cuz I think that would cause big shit! (I.E. Comes to mind there). Anyways it was more of an idea and a long way off for the moment, I am more interested in looking at binding mozilla to some form of byte code, I reckon if we can clean up the API to match and better .NET, then implement a decent runtime enviroment to interpret byte codes, I reckon we could give both java and .NET a good run for their money.
#73 Always playing catchup with Microsoft eh?
by bingobingo <firstname.lastname@example.org>
Thursday April 8th, 2004 8:41 AM
Why bother - you guys are forever playing catchup with Microsoft now. Why use something that is years behind the "hegemon"?
#90 Re: Always playing catchup with Microsoft eh?
Friday April 9th, 2004 10:33 AM
What are you talking about? XUL is real and has been used for years, XAML is still future, as is Longhorn.
#75 Always playing catchup with Microsoft eh?
by bingobingo <email@example.com>
Thursday April 8th, 2004 8:53 AM
Why bother - you guys are forever playing catchup with Microsoft now. Why use something that is years behind the "hegemon"?
Yes, Mozilla should join forces with other projects. To grow and to avoid doing things twice.
But should we really build this efforts on a fat, baroque kernel whose performance isn't the best? Shouldn't Apples favoritism of KHTML be counted as a shot across the bows? I don't vote for using KHTML, but for doing step one before doing step two. And step one should be redoing Gecko to get a competitive engine. Small and manageable are clearly not the last criterias when choosing a kernel to build on.
#81 Re: First thing first
by brendan <firstname.lastname@example.org>
Thursday April 8th, 2004 3:06 PM
- Apple picked KHTML *only* because it was smaller than Gecko by enough that Apple could hire people to learn to hack it in Safari's time to market. Period, full stop (yes, they were willing to fork it).
- Before hyatt went to apple, KHTML was way behind Gecko on web compatibility. Even now it lags, I'm told, but it's catching up. Still, nothing matches Gecko's reach: Active X, SVG, MathML, XPath, SOAP/WSDL, etc. KTHML even improved via Safari is still years behind that.
- We don't gain *anything* by rewriting for no feature gain or better integration. Gecko's footprint is actually *smaller* than KHTML's at runtime, counting dynamic memory as well as code. And Minimo (see <http://www.mozilla.org/projects/minimo/>) is pushing Gecko's minimal configuration, and default build size, smaller all the time.
You really have a strange idea of competitive if your only metric is "what did Apple choose".
I understand that there's not single criteria for "best" and therefore no best engine. And my reason for being a Mozilla hacker isn't because I think Gecko is not good. But I also see, with Apple's decision as an example, that lean and clear are aspects that are considered when deciding for one or another engine. And with more straightforward code Gecko could also catch up in speed with KHTML or Opera. Both are behind in standards compliance now - but if we rest on our laurels they're good and fast and that was it.
And yes, I know how good Mozilla competes in <http://126.96.36.199/page-loader/loader.pl>, but performance falls behind the competitors when it comes on big files, especially if they consist of tables.
> especially if they consist of tables.
Mozilla's table implementation largely prioritizes bug-compat with IE over performance. There are large wins to be made here, especially if we drop some of that bug-compat. The problem is that pages depend on it....
> And step one should be redoing Gecko to get a competitive engine
What exactly do you think dbaron, roc, myself, jst, sicking, peterv, etc are all working on?
don't get me wrong, I'm sure you're working hard on things I couldn't do and I appreciate it. The thing is that I couldn't notice improvements at a grade that promise to catch up to the "others" soon. There are 3% here and 6% there. But for the pages I use to test, Gecko/Mozilla takes about factor 3 to render.
And now you write about this (nice to read) vision on technology platform and something like a Mozilla desktop. This makes me fear man power will be tied on other places. But the nicer, faster and more easy the engine itself is, the more projects will be build on it. So having an attractive engine other people will use and spread it -> the Mozilla Project doesn't have to do it all itself.
And of course (thinking egoistic) browsing will be even more fun.
Don't you think if there existed a chance to gain 20% in one step that it would have already been taken?
Which pages are these? There are very specific cases in which gecko is known to be slow but, for general web pages, I certiianly haven't noticed anything like a factor of 3 or a factor of 6. Can you give an example of a site that shows those sort of problems and the exact conditions under which you see them?
#103 Re: Re: Re: First thing first
Sunday April 11th, 2004 10:11 PM
> But for the pages I use to test, Gecko/Mozilla takes about factor 3 to render.
Are there bugs on these? Usually, when we're that much slower there's a particular bottleneck being hit by the page (usually an O(N^2) algorithm that just needs fixing). Unless the bottleneck is one of the very few ones we already know about, chances are we can fix it without too much trouble.
#111 Re: Re: Re: Re: First thing first
Thursday April 15th, 2004 6:36 AM
>> But for the pages I use to test, Gecko/Mozilla takes about factor 3 to render. > > Are there bugs on these?
Yes and no. One of these is <http://selfhtml.teamone.de/navigation/syntax.htm>, validated ok by W3C. Even loading it locally from disk, it takes 2,1 sec with Moz and 0.9 sec with Opera 7.5 and about 0.6 with IE 5.
Differences will not be that noticable on faster machines (mine is a 800 MHz Duron), but still the same factor I guess.
#104 Re: Re: Re: First thing first
Sunday April 11th, 2004 10:12 PM
Oh, and I dunno about this "couldn't do" business. You probably could if you invested a bunch of time getting up to speed on it; it's just a rather steep learning curve....
#109 Re: Re: Re: First thing first
by brendan <email@example.com>
Monday April 12th, 2004 2:05 PM
> There are 3% here and 6% there.
That's a typical (high, actually, more like 1-2%) range for conceivable incremental improvements to any fairly mature codebase. If you've been around software a while, and looked at profiles, you learn that it wasn't the last cookie you ate that made you fat or slow. To mix metaphors, the "low-hanging fruit" to pick is in the 1-6% range. This is true in KHTML (post-Safari) too, from what I'm told.
To get bigger speedups requires algorithmic redesign, which takes time and risks losing open source quality assurance effects by breaking too much at once.
#78 First solve your home brewed problems.
Thursday April 8th, 2004 12:16 PM
Do you believe you can fight against Longhorn before solving the home brewed problems first? Don't you think that there has to be some reasons why Apple and KDE (Suse) choose kHTML instead of Geko? I'm not saying Geko is bad but there _are_ reasons.
Mozilla lost a rather lot of sympathy when a silly marketing guy named the new browser "firebird". Isn't Mozilla good enough to keep its name. Why is a new name needed?
"5) Create a technology platform on top of which applications". Phantastic maybe when this is finshed I finally know how to write my folder popup box extension for Thunderbird. So far I couldn't find any usful infos. BTW why did Mozilla remove this little nice item after version 1.0? Didn't they know that the folder pane can be hidden? How can one switch folders if the folder pane is hidden?
"Second, Linux is poised to rise just by being cheaper". True as long as Linux isn't usable by a normal user, a house wife, a carpenter, etc. but requires at least a master degree in computer science or immessurable time, costs are irrelevant.
Mozilla has to stay cross platform, after all this is the main reason to choose Mozilla.
"A crucial features of this new platform: the GUI toolkit must be able to blend in among native apps". When I see such a statement I always wonder why it isn't named wxWidgets (wxWindows)? Maybe the main problem within Mozilla is that it tries to do everything instead of using what's there. Do they Mozilla people really think they are able to build a better GUI toolkit besides the best browser, the fastest renderer, the most advanced technology platform, etc? How many are working on such a system and how many centuries are planned?
IMO Mozilla has its chance to "stay in business" if it concentrates on what it can and make corrections where it's needed. So Geko has to be tweeked that it is on a similar level as kHTML, that is IMO the most critical path. Do everything else what you planned but don't do it yourself again. At least don't do it where others already have succeeded.
#82 Re: First solve your home brewed problems.
by brendan <firstname.lastname@example.org>
Thursday April 8th, 2004 3:10 PM
See my last reply here re: KHTML and do your homework before making browser engine comparisons by arguing from authority (Apple's or KDE's).
We gained sympathy and avoided a destructive fight by renaming Firefox, because the Firebird open source database project wanted to keep that name in trademark category 9 (software and electronics).
If you have a thunderbird extension question, try asking mscott -- he'll probably be able to help you.
The rest of your comments seem to be addressed in <news://news.mozilla.org/n….public.mozilla.seamonkey>.
#96 Re: Re: First solve your home brewed problems.
Saturday April 10th, 2004 6:17 AM
I haven't been able to locate your reply "re: KHTML and do your homework before making browser engine comparisons ...".
About the thunderbird extension I already asked in the thunderbird features list and also mscott but neither got an answer. Just search once all forums with "Wyss" ;-)
#97 Re: Re: Re: First solve your home brewed problems.
Saturday April 10th, 2004 1:21 PM
I hope you are not refering to this: <http://forums.mozillazine…=18172&highlight=wyss>
#110 Re: Re: Re: Re: First solve your home brewed problems.
Monday April 12th, 2004 11:09 PM
Of course, this was the first message I wrote: There are two more but they are more difficult to find. Essentially they contain the same. Is there a reason that you hope not?
#108 Re: Re: Re: First solve your home brewed problems.
by brendan <email@example.com>
Monday April 12th, 2004 2:01 PM
> I haven't been able to locate your reply "re: KHTML and do your homework before making browser engine comparisons ...".
I am referring to my last post before the one you reply to, namely: <http://www.mozillazine.or…back.html?article=4584#81>.
#91 Re: First solve your home brewed problems.
Friday April 9th, 2004 11:52 AM
> Do you believe you can fight against Longhorn before solving the home brewed > problems first? Don't you think that there has to be some reasons why Apple > and KDE (Suse) choose kHTML instead of Geko?
You haven't understood what Brendan was saying. Microsoft has the power to turn the internet into a different thing where XAML is _the_ key technology for the new applications that are actually web pages. When this time has come, it does not matter anymore if khtml code is easier to understand, which renderer renders faster or whose browser's UI is cleaner. ALL browsers as we know them will be obsolete in this new world.
Mozilla alone already _has_ XUL, which is basically the same what XAML will be. Mozilla is already sort of an internet application framework as Longhorn will provide one. Mozilla has the advantage to be years ahead! But this framework is virtually not used (partly because not being very friendly to use) and not integrated with other projects. This is what Brendan is about and this is what needs lots of work to have only a slight chance of concurring with Microsoft.
Other browsers? Opera? KHTML? Forget them. Or tell me how they can provide a similar framework.
> IMO Mozilla has its chance to "stay in business" if it concentrates on what it can > and make corrections where it's needed.
Yes, and it is trying to. It already is a framework but has to be improved. Other browsers are not and therefore are not likely to stay in business. Users won't care if a old-fashioned browser renders pages faster as long as it does not render their web applications at all.
> So Geko has to be tweeked that it is on a similar level as kHTML, that is IMO the most critical path.
Define "level". Its speed is increased constantly, see <http://axolotl.mozilla.or…63&avg=1&days=700> It's size also. Just for comparison: Safari 1.0 was 4-5 MB smaller than Firebird builds last summer. Current Safari 1.2 is only 1.8 smaller than current Firefox nightlies (while being almost 1 MB larger than Safari 1.0). khtml has to catch up to Gecko (functionality-wise), not the other way. And doing so is not possible without getting bigger and bigger. Firefox downloads might even get smaller than Safari, maybe already during 2004. But as I said, this will not matter in a few years.
#101 Re: First solve your home brewed problems.
Sunday April 11th, 2004 9:40 PM
>"Second, Linux is poised to rise just by being cheaper". True as long as Linux isn't usable by a >normal user, a house wife, a carpenter, etc. but requires at least a master degree in computer >science or immessurable time, costs are irrelevant.
Linux isn't usable by a normal user? Work is in progress in this problem, don't worry. :-) Do you know GNOME <http://www.gnome.org/>? GNOME is a project that aims to provide a easy, user friendly and free desktop for Unix environments. Do you know GNOME's HIGs <http://developer.gnome.org/projects/gup/hig/>? Has got Mozilla any project like this? I think that it would be interesting for Mozilla a department working in those issues. Do you know Epiphany <http://www.gnome.org/projects/epiphany/>? Look at the Epiphany manifesto <http://www.gnome.org/projects/>. Epiphany uses Gecko. I think that Epiphany is more easy for end user that Mozilla Firefox, and Epiphany is integrated with GNOME desktop. Do you know Evolution? <http://www.ximian.com/products/evolution/> Is a groupware software with e-mail, calendar, etc., potent, user friendly, and easy.
Another thing, GNOME is very user friendly with international users. GNOME sets the language of applications by users's system language default.
Excuse my English, I'm Spaniard.
-- Alberto ¡ÑU!
#102 Re: Re: First solve your home brewed problems.
Sunday April 11th, 2004 9:44 PM
Excuseme, Epiphany manifesto is here: <http://www.gnome.org/proj…umentation/manifesto.html>
#85 my wanting-to-be-helpful suggestions
by nebajoth <firstname.lastname@example.org>
Thursday April 8th, 2004 11:36 PM
- Parrot (Perl 6) for high-level languages interpreter - EVAS for opengl rendering engine
You're talking mighty good sense, man. Mighty good sense. I feel empowered simply by reading what you've said. We can defeat the hegemon. We have better ideas, better tools, better methods, better code, and better coders.
#94 abstract goals vs concrete goals
Friday April 9th, 2004 7:55 PM
I really like the vision but I find it to abstract. I think it could be enhanced by identifying some existing software that could have been designed on the Mozilla platform and make it as a goal to offer a solution to re-design this software using Mozilla technology. Also, as pointed by the author, we should think beyond the web browser. Rich Internet Applications is a good name of the goal we want to reach.
1. Flex and Laslzo represent the underlying technology. But Macromedia Central is really what we are after I think.
2. in terms of software I would like to able to build on top of the Mozilla platform: - Skype-like client for VoIP and IM (this means embedding SIP stack and various codecs on the mozilla platform) - front-end to web services (think MAB for Amazon.com) - kiosk-like application - add your favorite app here
3. I have been playing with XUL, Flex and Laszlo and my first reactions are:
a- Flash is eye candy and Mozilla today has a hard time competing with it. But we could imagine to include some cool effects and animation as part of the Mozilla API.
b- Flex and Laszlo are limited in terms of the API they offer. Security is restricted, few protocols are supported.
c- Flex and Laszlo development model is much much simpler than Mozilla/XUL. Most functionalities are embedded in tags and the user does not need to be aware of the machinery underneath. Deployment is much simpler: one XML document as opposed to some RDF black magic for XUL.
I think that for a) and b), the choice will be based on the application. I am sure that Laszlo and Flash will add new functionalities. For instance a company offers a Jabber stack written in ActionScript. I am sure that fancy effects can be added in Mozilla/XUL.
For me c) is much more important. Today Laszlo and Flex remind me of HTML circa 1994-5. You see a cool app, you look at the source code, you copy and paste and here you go. This is learning by stealing or learning by plagiarizing. My experience with XUL is that this is not as easy and I think this is will be the major obstacle to mainstream acceptance.
Another very important aspect will be platform where the technology runs. Flex targets Falsh 7+. Laszlo targets Flash 5+. I have tried a Lazslo app on a PocketPC and it runs but it is very slow. Sony Clie has a Flash player. I am not aware of Mozilla running on PocketPC or Palm. This is another big differentiator when picking a technology for Rich Internet Application.
#107 Re: abstract goals vs concrete goals
by brendan <email@example.com>
Monday April 12th, 2004 1:57 PM
To get concrete, we need to agree on the high level goals across the alliance. So I started there.
Your post makes some great points that I agree with 100%. I'm not experienced with MXML enough to say how a future XUL + SVG + SMIL might compete, but it's clear there would be more XML namespace selectors on tags, and more indirection through w3 and other standards, whether _de jure_ or _de facto_. This hurts ease of use as well as footprint and performance. So I'm very interested in unifying languages that pull in tags from other XML dialects, in a coherent and easy to use way.
For PocketPC-type device work in Mozilla, see <http://www.mozilla.org/projects/minimo/>. Currently targeting GPE linux handhelds, but WINCE and PalmOS6 are possible future targets. Minimo has no XUL though -- it's "just a web browser".
A few weeks ago, I started a wiki page about Mozilla's application framework. It's up at <http://kb.mozillazine.org…v_:_Application_framework> (Linked from <http://kb.mozillazine.org/#Development>).
I marked it as a stub because I really don't have enough experience to clarify the finer points but now would be a great time if any of you could take a look at it and make any changes you see fit.
Great. Maybe this will mean that in the future copy and paste will work between Mozilla and the GIMP ;)