LOL!
i only tried XUL and XPCOM once(nearly 4 years ago)... and i lost interest in it after
a month or so since it meant convincing alot of ppl to use mozilla(or a XUL-app launcher)
to launch my applications... that was the reason i shifted to XSLT and XML (to generate
standard html and javascript dom objects)
Andy Sy wrote:
Amazing stuff. Yet another reason to go Mozilla. I always believed that you could write Rich Internet Applications (RIAs) using XUL. Can anyone else
see the implications in a corp setting? Take that, IE!
XUL itself is really really cool. But the other parts of what you need to make it work on Mozilla are real turn offs. I have two major complaints against Mozilla XUL:
* You can only use Javascript to script it. * Whatever simplicity and immediacy of getting up to speed XUL brings to the table, RDF destroys completely.
One only need browse the source code (via web cvs) of the XUL-based Amazon browser at http://www.faser.net/mab/ to see how such an apparently (or what _should be_) a simple application has a code structure (the Javascript portion) that is very hard to wade through and far larger than expected (I'm forced to eat Javascript for breakfast, but have to admit to being hopelessly spoiled and seduced by Python).
Still, Thunderbird, the Mozilla Suite, Firefox and other XUL-based offerings (the above are written in C++ by the way) are proof of how XUL has come a long long way indeed.
The beautiful cross-platform widgets are just sweet. XUL proper, as a means of specifying a UI is waaaaay more compact and in my view, faster to accomplish stuff with than any other method you will come across, including visual RAD. Compared to Mozilla XUL, just about all other XML-specified GUI technologies out there (including the much touted XAML), are hopelessly verbose. XUL is KISS incarnate.
But to reiterate, the reason I have yet to use it today is because of a) the requirement to use Javascript (and/or C++ for which you have to learn XPCOM), b) to wrap your head around RDF, and c) the convoluted packaging requirements.
In a perfect world, we'd have Python (and other language) scriptable XUL specified GUIs without the need to learn a complex packaging skeleton and free of RDF.
Python scriptability would be heavily dependent on how elegantly Mozilla's XPCOM object model (inspired by Microsoft's COM and thus undeniably C++-centric) maps onto Python's. You want the Python (or Ruby, etc...) equivalent of XPConnect (Mozilla's XPCOM-to-Javascript bridge).
XPCOM is used because of the theoretical benefits of its being language-independent (like COM itself), but after seeing some XPCOM (and COM) examples in Python, you will realize such 'benefits' come at the cost of a lot of painfully ugly code. A bridge technology connecting XUL to Python analogous to how XPConnect works for Javascript would effectively hide a lot of the XPCOM guts, and bring the promise of XPCOM to fruition (much like how COM, despite all its C++-centricness is exposed more or less nicely in VB).
Or perhaps, someone can 'steal' XUL's cross-platform widget rendering code and wrap a non XPCOM-based, designed-from-scratch API around it.
-- Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
