to do anything useful with it because of all the extra security stuff,
and, dare I say, lack of bountiful, up to date information on how
to deal with it. Signing applications is simply way too complex
for most developers to handle. If it was easier,
more people would be distributing signed apps which did cool stuff.

In addition to being non trivial, the mozilla platform is a moving target. Just look at how many (mostly) trivial extensions break between versions of mozilla and firebird. Most application developers will only adopt something like mozilla if they have some guarantees that their products will work with future mozilla versions. Basically you just want to create your application, install it next year on whatever mozilla version is fashionable then and not have to worry about whether it will work.

Mozilla Firebird is a "Technology Preview" and thus compatibility isn't guaranteed between any of its versions. mozilla.org has only released two (perhaps three) versions that are considered stable APIs. Many extension developers, however, continually update their code for every Mozilla and Firebird release, and often nightly builds.

Many of the 'trival extensions' often rely on specific features of the browser, such as things to overlay, code in navigator.js/browser.js and certain UI. It isn't possible to maintain complete compatibility in many cases. I don't know of any application that allows the level of customization that Mozilla does. The power comes at a cost in compatibility.

I worked on a couple of mozilla apps for companies that were run off of CD-ROMS. They were slick multimedia/knowledge base type apps. We took advantage of adding plugins to mozilla and used Flash for fancy diagrams and such. They were medium sized projects. We ended up skinning the mozilla UI to make it blend in perfectly with our mozilla app. It worked pretty good. I think the same problems that Java originally faced XUL now faces: basically you can't run a downloaded Gecko app. without the GRE. Most people don't have the GRE. This is the same problem with Java. No JRE on the client computer and the app won't run. Realistically most IE users see no reason to install Mozilla since they are happy with their just-good-enough browser. I was excited when I heard the KDE people are experimenting with running the UI using an extended version of XUL widgets. That would be very cool. So any XUL developer running KDE could write a Gecko app and expect an XUL interpreter to be available. Possibly Mozilla apps. would really benefit if both Gnome and KDE could run Gecko apps. by default. This might actually happen on KDE pretty soon. Maybe Mozilla.org could sue Microsoft and get the GRE installed by default on Windows (joking, but I wished it happened).

> I was excited when I heard the KDE people are experimenting with running the UI using an extended version of XUL widgets. That
> would be very cool. So any XUL developer running KDE could write a Gecko app and expect an XUL interpreter to be available.

Note, that KaXul and uXul is an independent build that also works as a plugin in Konqueror. There's no need for Gecko. You might wonna read the XUL News Wire story titled "KaXul and uXul: XUL for the KDE Linux Desktop Talk Slides Now Live" for details online @ http://article.gmane.org/gmane.comp.lang.xul.announce/154

- Gerald

PS: I would be great if some Mozilla officials could comment on KaXul and uXul. Is this iniative in your interest? Do you plan to sue? Have you contacted the project leaders? Open source is all about open communication and not behind closed door wheeling and dealing. You might wonna adjust your attitude because the glory days of AOL or Netscape are over if I dare to say.

"I would be great if some Mozilla officials could comment on KaXul and uXul... Do you plan to sue?"

I'm not a Mozilla official but from what I can tell from their pretty presentation http://www.staikos.net/~staikos/presentations/August2003/kaxul/, KaXUL and uXUL follow the XUL specification. As far as I can tell, KaXUL essentailly converts a XUL app into a KDE app, while uXUL takes a XUL app, uses KaXUL to convert it and then runs it. Now if it was a project to convert applications written in some other random XML-based declarative markup language that just happens to bear a passing resemblence to XUL to KDE apps, that would be different because they would be using the XUL name to apply to something that isn't really XUL.

KaXul and uXul remind me why I still like KDE over Gnome: I have always felt KDE is cooler, looks better, is more intutive, and easier to customize. Everything cool like uXUL appears to come out on KDE first. What's up with that? Is their developer base just better or larger?

> As far as I can tell, KaXUL essentailly converts a XUL app into a KDE app, while uXUL takes a XUL app, uses KaXUL to convert it and
> then runs it.

Well, if I dare to say KaXUL and uXUL just happen to bear a passing resemblence to Mozilla XUL. You can't just grab any Mozilla XUL apps and run them on KDE using Konqueror. uXUL and KaXUL just uses a toolkit independent XML UI Language that reuses XML tags pioneered by Mozilla XUL to lessen the learning cure. Don't expect XPCOM, XPIDL, XPInstall, RDF, and other monstrositis showing up in uXUL and KaXUL anytime soon.

- Gerald

PS:
> KaXUL and uXUL follow the XUL specification.
Do you really think KaXUL and uXUL will support the Mozilla XUL XPIDL interfaces outlined in the abandoned "specification" working draft last touched up in 2001?

PPS: Care to comment on Luxor XUL online @ http://luxor-xul.sourceforge.net ? Does it apply the XUL name to something that isn't really XUL? Is it just a random XML UI Language? How about the Perl XUL project online @ http://perlxul.sourceforge.net ?