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

Also worth mentioning

[Anonymous Coward]

PyXPCOM, for Python-scriptable XUL applications, should be available shortly.

XULRunner future.

[Tei]

Even if Mozilla evolve to XForms base, will be posible to continue XULRunner as a separate project. So XUL is here to stay.

XUL is very good RAD tool. Much.. much much better than HTML. Because with HTML you sould care about styles and other miscelanea problemas, and becasue with HTML you badly emulate OS widgets, with XUL you use OS widgets.

Also good bonuses are easy to code with javascript, and the integration with XML (indeed!).

Re:XULRunner future.

[ObsessiveMathsFreak]

XUL is very good RAD tool. Much.. much much better than HTML.

I would classify XUL as a good GUI development tool. It's rapidity is quickly lost if one delves into any XPCOM backends.

However, for simple, client side, frontend GUI operations, XUL is a very, very useful tool. It gives you the ability of DHTML in a way that isn't a hack.

Here's a good example of XUL's layout capabilities. IN terms of pure layout, there not really that much here that is different from HTML. However when you get dynamic, XUL really shines. People go on about AJAX, but XUL offers a huge amount of potential.

Personally, I feels XUL's only achilles heel is javascript. That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

As a GUI application development tool, I would expect XUL and XAML to replace older methods such as GTK and *shudder* Windows "Visual" code. It's faster, cleaner, makes more sense, and you don't need 300 lines of code plus libraries to draw a hello world window.

Oblig. Ghostbusters

[shepmaster]

"There is no Dana, only Zuul."

Or, as the Wikipedia points out:

"There is no data, only XUL"

This is what lost the browser wars

[Bogtha]

Back when the browser wars were in full swing and the Netscape source was just released, Netscape was at a huge disadvantage - they were fighting against Internet Explorer, which was bundled on every new desktop. However, they had an ace card - they were the browser of choice for ISPs.

Back when everybody was on dial-up, the usual way to get on the Internet was to get disks or CDs from ISPs, and run their installer. Typically, that also included Netscape, which was subsequently set to be the default. So while Microsoft had a browser installed by default on every desktop, Netscape was installed over the top of that for most people who signed up for dial-up service.

Then the Netscape source was released, and Netscape 5 was overdue. There was missing code, so it didn't build. Instead of filling in the bits that were missing, fixing the most prominent bugs, and releasing Netscape 5, practically everything was thrown away and they started again - to build a new platform based on Javascript and XML (and, oh yeah, with a browser I guess). XULRunner is the culmination of that process.

However, this came at a cost. Throwing everything away and starting again set back the development by a huge amount - it took over four years to go from the public release of Netscape's code to the first release of Mozilla. In the meantime, Microsoft released three new versions of Internet Explorer.

So what choice did ISPs have? Ship the outdated Netscape 4 to all their new customers? Ship a buggy prerelease Mozilla build to all their new customers? Pay Opera for every new customer? Or just bundle Internet Explorer? Of course they did the latter. The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.

So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough. But when I think of the stranglehold Internet Explorer has had on the market for so many years, and the pain that has caused me as a web developer, I can't help but think that the price was way, way too high for what is essentially just another cross-platform toolkit. Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

Re:This is what lost the browser wars

[Anonymous Coward]

So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough.

No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

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. (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)

Unfortunately for me, I've never figured out exactly WHAT the closure takes with it. I know of no way to check the current environment to find out what your function accidently wound up keeping. However it does explain the "delete" keyword that had always confused me. Why do you need delete in a GCed language? Well, because without it, you can wind up with pointless variables that were supposed to be local that are accidently kept in a closure!

Next we have XUL and CSS. XUL isn't native - I think everyone's noticed that by now. Firefox manages to goof up the scrollbars, so they don't match my theme. They also goof up form controls, so that they don't match my theme. Under Windows, certain controls don't act like Windows controls. I'm told the situation is even worse under OS X, but I've yet to convince management that I need an OS X machine to test on.

Like you said, XUL was a horrible, horrible, horrible mistake. It should never have been made. They should have released Netscape 5 and worked on making a usable browser. Firefox is an interesting tech demo, but it's not something I'd want to support indefinitely. Quite literally the only reason people use Firefox at all over Opera is because it's open source. Were Firefox closed source, Opera would be the clear victor.

Yes, I know: XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms. Because of XUL, the entire core browser is a giant mess of CSS, JavaScript, XML, and XPCOM. XUL is an interesting concept, but it just fails in implementation. The insane hacks required to make XUL appear to be native are proof enough that it just isn't a smart design.

People often joke that Emacs is practially an operating system. With the release of XULRunner, Firefox has proved that it literally IS a complete operating environment. It contains all the libraries you need to write full applications. In a sane world, that would be called "bloat".

Re:This is what lost the browser wars

[Bogtha]

No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

Decent enough for browser plugins. Decent enough if you are building an application that is very closely related to browsing. I wouldn't choose it for building general-purpose applications, no.

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.

Well no, you might expect it to leave scope, if you assumed Javascript worked like some other language that doesn't support closures, but that's not the way Javascript works, so it's not supposed to leave scope.

Unfortunately for me, I've never figured out exactly WHAT the closure takes with it.

Richard Cornford wrote a decent explanation.

XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms.

I think that's an implementation detail rather than anything intrinsic to XUL itself. There was an experimental "KaXUL" to implement XUL within KDE and Konqueror a few years back, but I don't think anything came of it. As far as I know, there's nothing stopping a XUL implementation from rendering XUL applications with native widgets, it's just the people who built the only functional implementation chose not to.

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: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.

XUL: WIkipedia

[eltoyoboyo]

Here is the Wikipedia article on XUL. I could have used this link on the PERL 6 web site since the documentation on PARROT and PUGS are composed in XUL. This was my first introduction to the format. The documents opened in Mozilla, but not in IE. While the arguement has been made here that you should only use Mozilla, why alienate a huge chunk of users without helping them along? Also, if you are going to publish in XUL, do not assume the casual user knows what the format and reader is. The Filext.com site did not yet have a listing or recommended reader for the XUL files.

Re:What is the language?

[Bogtha]

XUL is an XML-based language that lets you define a user interface for a program. You hook it all together with lots of things web developers already know - it uses Javascript, the DOM 2 Event model, extensions to CSS, etc. You can use it to build stand-alone applications with XULRunner, or extend existing XUL applications like Firefox.

Frequently when people talk about XUL, they mean the whole system that makes XUL work - which includes the Javascript, CSS etc. "XULRunner" doesn't "run" XUL, it takes the user interface definition files defined in XUL, and executes the Javascript, renders the CSS, etc, to make it all work properly. XUL is just one component in the grand scheme of things.

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.