A Brief Introduction To XULRunner: Part 1
- 1 What is XULRunner?
- 1.1 What Makes XULRunner a Platform?
- 1.2 How Does Firefox Fit into the XULRunner Equation?
- 1.3 That's Fantastic, Really. But What the Heck is it?
- 1.5 Oh, So Why Would Anyone Want to Use XPConnect?
- 1.6 Hey, Slow Down! What's this XPCOM Thing, Now?
- 2 Why Use XULRunner?
- 3 How to Use XULRunner
What is XULRunner?
XULRunner is the name of a platform (framework) developed by Mozilla for their flagship web browser, Firefox. [Note: anachronism! XULRunner used to be called GRE, the Gecko Runtime Environment. And before that it was called XPFE, the Cross Platform Front End. It was developed by Netscape for their flagship web browser, Netscape Navigator.]
The best analogy to explain XULRunner is to imagine the Firefox web browser, stripped of its user interface. That means, Firefox without anything the user can see, touch, or interact with in any way. On the surface, this sounds like Firefox just goes away in a *poof* with a press of the delete key. But really, that's all the "Firefox" part of the application is: the user interface. The hidden engine that makes it all come together as "Firefox" is XULRunner.
What Makes XULRunner a Platform?
XULRunner is kind of like Java. Some of the main differences are subtle, but important; Java is the name of a virtual machine (Java byte code interpreter), the name of a framework (a huge library of programmable objects and classes), and the name of a programming language. XULRunner is a bit like Java's VM and framework in one package.
XULRunner is also kind of like the .NET framework. The .NET framework is also a VM, like Java. And .NET is also a framework of objects and classes, again like Java. One thing that makes .NET different from Java is that .NET is not a programming language; .NET programs are typically written in the C# language.
However, XULRunner is not .NET, and it is not Java. The main thing that XULRunner shares with these technologies is that it is also a framework for cross-platform application development. In some ways, it even competes directly with .NET and Java.
How Does Firefox Fit into the XULRunner Equation?
Since version 3.0, Firefox has been built directly on top of XULRunner. This is not exactly how Mozilla envisioned XULRunner would be used, though. The original idea was to release the XULRunner runtime. And then at the same time, release XULRunner applications which would use it. Some of these applications would be Firefox, Thunderbird, Songbird, etc. Similar to the way which Java and .NET programs are released!
Sadly, XULRunner is not yet mature enough to make this a reality. So instead, XULRunner is "privately" included with Firefox, Thunderbird, and Songbird. This does bring one small advantage though: If your target audience has Firefox installed, they won't need to install XULRunner separately nor will you have to include the full 10MB XULRunner runtime in your application. Your users can just run your application using Firefox's XULRunner.
That's Fantastic, Really. But What the Heck is it?
OK, here's the straight-up truth in as few words as I can manage: XULRunner enables application developers to write rich-GUI programs that run on every major operating system, using languages and technologies that web developers are already familiar with.
That means, you write your GUI in a structured "language" based on XML; it looks a lot like XHTML.
Then you make your GUI pretty with CSS.
Oh, So Why Would Anyone Want to Use XPConnect?
Hey, Slow Down! What's this XPCOM Thing, Now?
XPCOM is the Cross Platform Component Object Model. Without getting too technical and knee deep in new acronyms and jargon, XPCOM is the general catch-all term for everything on the "other" side of the XPConnect fence. XPCOM is a strange and mysterious land that we will explore in a later adventure. For now, you can think of XPCOM components as a .DLL on Windows, a .SO on Linux, and a .DYLIB on OS X; it's really just a dynamically linked library, wrapped in an enigma.
Why Use XULRunner?
There are a lot of reasons to use XULRunner over, say, Java or .NET. And there are also reasons to use it over simpler cross-platform toolkits like GTK+ or wxWidgets. There are also reasons against using it, as you will see. I will try to explain some of the advantages and disadvantages faced by today's XULRunner application developers.
XULRunner vs. Java/.NET
Compared to .NET, XULRunner and Java both have a significant advantage in pre-existing platform deployment. Almost every computer system in the world has Java installed. With Firefox being one of the most used pieces of software ever, that puts XULRunner second in line behind Java. And finally, .NET support is available almost exclusively to Windows users, but its true deployment is likely far fewer in number than either Java or XULRunner.
Java's user interface support just feels like ... Java. Rarely does a Java program ever look or feel like any other native piece of software on any operating system. And .NET programs look and feel like Windows programs, even on other operating systems.
By contrast, XULRunner tries to mimic the native operating system GUI as closely as possible. That means it does not use 100% native OS widgets (and it would never work like that! Remember, XULRunner applications are styled with CSS) but it does make an attempt to look and feel exactly like a real OS GUI.
XULRunner vs. GTK+/QT
GTK+ is a very popular cross-platform widget toolkit which is totally native to the GNOME Linux desktop environment. So every GTK+ application feels right at home to a GNOME user. KDE users won't be too thrilled to find that GTK+ applications don't fit in with their QT-native desktop environment, though.
QT is the cross-platform widget toolkit that is native to the KDE Linux desktop environment. Interestingly(?) QT apps feel right at home on KDE, but feel out of place on GNOME.
GTK+ and QT are not limited to Linux; there are ports available for Windows and OS X, as well. GTK+ is fairly skinnable, so it can be themed to resemble native operating system GUIs. But some times it just doesn't "feel" native. The same could be said of QT.
XULRunner vs. wxWidgets
wxWidgets is a native OS widget toolkit written in C++. Almost all widgets provided by wxWidgets are native to your OS. They will look and feel right at home no matter where you run your application (if you can build it to run anywhere, that is). However, some operating systems do not provide all types of widgets that wxWidgets supports. Such widgets will be "emulated" with non-native widgets.
On Linux, wxWidgets always uses GTK+, even under KDE. So it will have the same problems as running a GTK+ app in a KDE desktop environment. XULRunner also only uses GTK+ under Linux.
That Doesn't Help Much. I Need More Persuasion!
That's cool. This gives me the opportunity to explain some of the advantages to XULRunner that you will not find in the other application frameworks discussed.
First of all is extensibility. Think of Firefox extensions: An extension is simply a very small XULRunner application that hooks itself into the "host" XULRunner application; Firefox. There is very little difference between a full XULRunner application like Firefox, and an extension for a XULRunner application. This makes the extension developer documentation great for XULRunner application developers, and vice-versa. This also means that anything your XULRunner application can do, can be done by an extension.
Hypothetically, if a user of your XULRunner application wrote an extension that you really liked, you could integrate that extension into your application as a standard feature. This is how a lot of experimental features are done for Firefox, even. You could also pull out a feature that you think really doesn't belong in your application core, and make it an extension only, so that users may optionally install that feature if they want it.
Another nice thing about XULRunner is its ability to be skinned and themed. If you are writing a digital audio workstation, and want to keep your application within the mood of other DAWs, you might want to make a totally custom theme for it that looks nothing at all like the native OS GUI. Media players often do this as well. Then there's the option of making your program look even MORE like the OS GUI, by slightly tweaking the default widget stylesheet to more closely match other native applications.
Internationalization and accessibility! (i18n and a11y) Even if you don't need these features, someone out there might appreciate them! You might have had experience with a program in the past which was written in a language you do not speak. Wouldn't it be nice if you could open that program in a text editor and run all of the user-facing text strings through an automated translator? You could potentially make that program readable and usable in about an hour, depending on how much there is to translate. But this usually isn't the state of things. Most programs are compiled with only one language. That makes them difficult to modify, and also makes them nearly unusable to anyone of a different nationality.
With XULRunner, your applications can be built from scratch with i18n awareness, and they really can be easy to translate. It's a similar story with a11y; visually- and hearing-impaired users should be able to use your program with screen readers and visual feedback.
OK! You've Convinced Me!
Good. Read on! :)
How to Use XULRunner
Continue to Part 2.