I finally pulled enough pieces together to get the next XUL Explorer release ready. Most of the new features in XUL Explorer 0.7 came from contributors which is cool. New in this version:
- Application and Extension project wizards have much better error handling and validation. The code was restructured so both wizards share a common base class. Thanks to Matt Crocker for the patch.
- Users can add external manifest folders to XUL Explorer. This is a great help when previewing a XUL file that references external chrome folders. Previously, an erro message would display (missing DTDs) or the XUL wouldn’t style correctly (missing CSS). Now, users can add the manifest folders to XUL Explorer using the Options dialog and the external manifest files will be included when previewing so everything looks right. Thanks to John Marshall for the patch.
- Autocomplete history lists were added to the Application and Extension project wizards to make it a bit easier to generate code to a previously used folder location. This feature was more about making autocomplete textboxes work and less about usability.
I had to stick with packaging XULRunner 220.127.116.11 (1.8.1 for Mac) because XULRunner 1.9 has a nasty bug that keeps the caret hidden in the editor window.
Download the latest version from here.
Update: I fixed the broken link to the Mac version on the MDC page.
Cesar has release an alpha release of WebRunner deployed as a Firefox extension and launched using Firefox as the runtime. That’s right, delivered using Firefox’s extension mechanism and launched using Firefox’s runtime. No XULRunner needed for this deployment. It seems to work on Linux, but we need to make some changes for Windows and Mac. Also, check out some of the WebRunner Planning discussion to see what ideas are being kicked around.
As Cesar says, we think this is a possible direction for WebRunner. We could do more. We’re looking for feedback. We are still working on the standalone XULRunner version of WebRunner and should have a new release out soon.
Ryan Paul posted an article on ArsTechnica that describes how Firefox 3 will be able to run XUL-based applications. Since the news is starting to spread, I thought I’d try to put some information out before the guesses and rumors start to fly. Ryan’s article describes the feature rather well.
firefox -app application.ini
Yes, this is different than anything previous versions Firefox could do with XUL. Firefox 2 (and earlier releases) could launch XUL windows using the
-chrome command line flag. Firefox 3 will be able to launch full blown XUL applications – running in their own separate processes and separate profiles. Up until now, XULRunner was the only way to deploy XUL-based applications. Some relevant information:
- XULRunner is not going away. XULRunner is still the preferred way to deploy a XUL-based application. XULRunner gives the application developer full control over the runtime.
- Firefox and XULRunner share much of the same backend code. When I say much, I mean nearly everything. Firefox is now capable of running XUL-based applications using the same type of bootstrapping mechanism as XULRunner. Since they share so much code, it was fairly trivial to enable this feature. Here is the bug detailing the code.
- When using Firefox 3 to run XUL-based applications, keep in mind that you are at the mercy of the Firefox 3 runtime. If an upgrade to Firefox happens, it could possibly break your XUL-based application. This is the down-side of sharing runtimes. Therefore, be very careful when using Firefox 3 to run your XUL-based application. Such a problem would not happen when deploying your application with XULRunner.
If it seems like we don’t want to promote running XUL-based applications using Firefox 3 as the runtime – good! This is very experimental and there are down-sides. There are no current plans to expand or extend the feature.
On the other hand, feel free to experiment with it. Just because Mozilla may not have plans to extend the feature doesn’t mean that you can’t. I can visualize a Firefox extension that could be used to download and install small XUL-based applications to a profile folder. The extension could manage the applications like Firefox manages addons.
Hmmm, downloadable desktop applications built using XML and web technologies running on software you already have installed. Sounds kinda cool.
If you have questions about building XUL-based applications and how to use the runtimes, feel free to post to the newsgroup or, better yet, drop by the #xulrunner IRC channel (irc.mozilla.org) and talk to a real live human being.
Okay, maybe my tongue-in-cheek, roasting of Ryan Stewart didn’t go over so well. But, at one point in the post/rant I mention working on a project called WebRunner that, IMO, is a competitor to Adobe AIR. I, unsurprisingly, feel that WebRunner does a better job complementing the Web and is a better fit for web applications in general. Both systems allow developers to run rich internet applications (defined as you wish) on the desktop. That’s in itself is both novel and interesting to many developers. However, I think WebRunner and AIR are suited to slightly different applications.
I see Adobe AIR as a desktop runtime for Flash applications. This is a nice boon to Flash developers who have long waited to escape the browser as a runtime. Although AIR supports running DHTML/AJAX/Ajax style web applications through its embedded WebKit renderer, this will likely be overshadowed by the Flash-based applications. Of course, this is just me talking, but most “applications” I have seen running in AIR are Flash-based.
WebRunner, on the other hand, is completely built around a browser – the same browser found in Firefox. Any existing web application should operate in WebRunner without any changes. Create an instant desktop version of your web application. Of course, its not really a desktop version – its just running in a Mozilla browser without any traditional browser chrome. WebRunner doesn’t change how you build web applications. It doesn’t impose a new stack of technologies, it works with the Web.
WebRunner does have the ability to add “features” to web applications such as:
- Support for simple desktop integrations like displaying alert popups, registering as content handlers for local files, and access to the file system.
- Greasemonkey-like application scripting to tweak the UI, access the simple desktop integrations or add offline features, not already built into the web application.
Its important to point out that these “features” are completely optional and can be added in a very mashup-friendly manner that most web developers and power users are already using.
There is definitely more to come from WebRunner.
Ryan Stewart has made a critical blunder in his attempt to create a Kawasaki-esque mantra for Adobe STEAM. This blunder will likely cause the failure of Adobe MIST and the eventual collapse of Adobe itself. I give you Stewart’s mantra:
Web-Enabled Desktop Development
Clearly, the man has lost his senses. Such bright promise – a pity really. Web enabling a desktop application is like embedding MSHTML in your MFC application and if this is Mr. Stewart’s vision of the future, perhaps they need to keep some windows open on the bus. I have been working tirelessly (not really) on a concept called WebRunner – similar to Adobe WIND, only better – and have also created a mantra:
Desktop-Enabled Web Development
The countless hours spent on my mantra were worth it and the distinction is so obvious even Google Translate could see it. Yes, ‘Web’ is the focus here – ‘Desktop’ is dead. Mr. Stewart is no doubt kicking himself over this whole incident. To show my empathy, I am allowing Mr. Stewart to use my mantra in place of his own (CC BY-ND).