. It is actually a little better than traditional development (at least in theory). -- AluoNowu
Seems that so far XUL's had a hard time catching on. Reasons seem to include PoorDocumentation?
, not playing well with NativeWidgets?
, and good support for only JavaLanguage
. Any other reasons? How much, if at all, have these problems been ameliorated?
Similar problems have slowed the adoption of OpenOffice
's UNO framework.
It has not caught on in a big way, but there are a number of XUL based applications listed here:
Some (Komodo Edit, Komodo IDE, SQLite manager, Songbird, Blue Griffin, Pencil) are reasonably widely used.
One thing that bothers me about XUL is that it is separate from HTML form widgets rather than an extension. That tends to force a boolean choice of whether to go with HTML or XUL. It would be nice to have extensions to HTML form widgets without sending one down the road of Yet Another Language. For one, somebody may want to abandon XUL for something that is compatible with more browsers. It would be easier to swap if HTML extensions were used.
- Not entirely true; with namespaces one can mix HTML and XUL. <hbox><html:div>Foobar</html:div></hbox>. It's harder to embed XUL in HTML, requiring the use of an XbL bridge. -- AndyEd?
Besides using Mozilla as the engine, there are other efforts to get XUL into more places. Luxor uses the XUL for describing the Swing widgets.
There are also interesting pages on the JinxWiki
(a wiki for Java) on the SwikiFarm
See also: MozillaBrowser