XULRunner Developer Preview Release Available

TeachingMachines writes "A stable developer preview release of XULRunner 1.8.0.1 is now available. Based on the Firefox 1.5.0.1 codebase, it is available for Windows, Mac OS X, and Linux. From the Mozilla Developer Center (beta): "XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. It will provide mechanisms for installing, upgrading, and uninstalling these applications. XULRunner will also provide libxul, a solution which allows the embedding of Mozilla technologies in other projects and products." Help with programming with XUL and its related technologies can be found at XULPlanet. Beginning programmers will benefit especially from the XUL Tutorial. Also check out the XUL Element Reference to get an idea of what's available. "

A couple of other resources are worth mentioning. First, there is the XUL Programmer's Reference Manual which covers interface elements for XUL version 1.0. "Rapid Application Development with Mozilla" is available for download at Bruce Perens' Open Source Series page. If you get the book, make sure to check out the errata. Unfortunately, the author Nigel McFarlane has passed away, so this is likely the final version. One final reference, "Creating Applications with Mozilla," is available here.

For those individuals who are looking for an extremely powerful application framework that is relatively easy to use, Mozilla is definitely worth a look.

Comments

Dev environment

[roman_mir]

I am working on a couple of extensions and I wish there was a dev studio, possibly an Eclipse plugin for xul/xbl/xpcom/javascript/css/rdf integration. With my extensions, which have a very small codebase, debuging is a completely manual process (not counting venkman, which is a good tool but still not powerful enough for my needs.) Certainly having a good design helps a lot, because most of the time it is clear, which component should be looked at. When I just started on the first extension, I didn't understand javascript enough to componentize, so after a while, I completely rewrote the code, because the single file with functions grew too much and any debugging became extremely painful.

I am also looking for a way to 'run' xul components without doing a full build, a visual studio perhaps, that could help with layouts and avoid all the annoying syntax errors. XUL itself is a markup language that is XML based and allows building visual components - dialogs, menues, buttons, tabs, grids, textboxes, etc. While you can open a half done HTML page in your browser and see what is going on, with XUL you have to build the package first and then you can see what's going on (an incorrect XML structure in this case will give you an error, XUL must be well-formed and valid.)

XPCOM brings other challenges. It is a native library of services/components that can be accessed from javascript (or possibly other scripts) and that extend the functionality of the script to include things like file management, access to preference storage, window manipulation, etc. But you can't just run a compiler to see if you are doing everything correctly, you will only get errors in runtime.

Actually, I think this is the biggest problem - all errors must be caught in run-time. Javascript, XUL, XPCOM work, XBL, everything can be built (there is nothing to building anyway, just packaging really,) but after the packaging errors have to be caught in runtime, and I think this is always the biggest problem for a programmer who is used to rely on compiler to quickly catch some of the problems before even starting the application.

Maybe there needs to be a unit-testing framework created, that can help running unit tests on portions of the code without building the entire application and catching unit errors during execution of the entire application. Yes, actually, to think about it this could be a big help, especially for the new developers, who can be put off this entire platform because of lack of these tools.

Re:This is what lost the browser wars

[tetromino]

First off, JavaScript. It doesn't matter if you can use XUL from other languages because parts of it are implemented in JavaScript. JavaScript is a horrible, horrible language. I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure. Lisp/Scheme developers know what a closure is. JavaScript developers probably don't.

I suspect that I am feeding a troll, but here goes...
Your comment is much akin to the following:

• C is a horrible language -- pointers are too hard
• Java is a horrible language -- I can't wrap my mind around object-oriented programming
• Perl is a horrible langauge -- regular expressions confuse my poor brain
• Lisp is a horrible language -- parentheses terrify me
• Python is a horrible language -- I keep on messing up the indentation

Bottom line: if you can't be bothered to learn the grammar of the language you are using -- hell, if you don't find learning new languages and grammatical concepts positively exciting -- perhaps software development is really not for you. You might want to look into becoming a manager.

Re:OK

[Anonymous Coward]

The GUI builders are the same place where good HTML builders are: emacs or a good text editor! Good web developers don't use wysiwyg HTML/XML editors. It is easier and more reliable to just know the markup language, CSS and preview in a browser.

Re:This is what lost the browser wars

[NutscrapeSucks]

The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.
Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

I'm sure many people remember the line from mozilla.org -- "It's not a Browser, it's a Development Platform!!" Urg.

Unfortunately, Mozilla (aka AOL) did not understand the fundamentals of what they were getting into. "Development Platforms" are far less about capabilities and a lot more about Tools. It's just confounding that they sunk soo much effort into developing XUL, and then never released documentation, never released a GUI builder, never really built a community.

Even ignoring the overall irrationality of the AOL building their own GUI Toolkit, it's just totally bewildering that they only went 80% of the way there. If one wants to compete directly with Microsoft and Sun in the devtools market, you really have follow through, not just throw a bunch of code out on a FTP site and then wonder why nobody's using it. They really did throw away 50% marketshare with nothing to show for it.