I’ll be taking part in the Free Software and Open Source Symposium (FSOSS) hosted at Seneca College. In addition to the symposium tracks, there is also a set of workshops. Checkout the various speakers and topics. There’s lots of good stuff going on. Seneca’s deep involvement with open source has always impressed me.
Cesar and I will be doing a workshop on desktop-enabling web applications. No surprise, we’ll be using WebRunner to desktop-enable some webapps. We’ll try to make it interesting by using webapp scripts and styles to add some new behaviors and look & feel.
After much fooling around, WebRunner 0.7 is ready to release. This release has some small changes and some big changes.
- The WebRunner command menu has been removed from the context menu and is now on a statusbar button menu. The commands had nothing to do with the web application content, so the context menu was a bad spot for the commands. See WebRunner:HostWindow
- The statusbar is no longer allowed to be hidden. The status messages and progress meter, used during a page load, can still be hidden using the status config parameter. The statusbar is where the SSL lock information is displayed and we feel its important enough to always be displayed. See WebRunner:HostWindow
- The simple INI webapp file used to configure the web application has been changed to a zipped archive. The configuration file is now inside the archive. Also, inside the archive are the window and desktop icons associated with the web application. In addition, an optional script file can be placed in the archive and used to tweak the WebRunner chrome window for the given web application. See WebRunner:Bundle, WebRunner:Config and WebRunner:Scripting
- The WebRunner host window now has an optional Sidebar component which can be enabled using the configuration file and initialized via the webapp script. See WebRunner:Config and WebRunner:Scripting
- WebRunner now installs web applications into its profile/webapps folder. Any web application launched via a webapp bundle (the zip archive) and has an ID (new configuration parameter) will be unpacked into the profile/webapps folder. Afterward, you no longer need the webapp bundle and you can launch the web application using the installed copy. See WebRunner:Bundle and WebRunner:Config.
- WebRunner can create a shortcut to an installed web application on your desktop. The shortcut uses the web application icon. On Windows, a normal shortcut .lnk file is created . On Linux, a .desktop file is made using the web application icon. On OS X, an application bundle stub will be created (not implemented on OS X yet, sorry). We will get this working on OS X ASAP.
Installs for Windows, Linux and Mac can be found here. You can also find some example webapp bundles there too. The GMail bundle has an example webapp script that watches for new mail and displays a popup notification if any new mail arrives. I also added new webapp bundles for Facebook and Twitter.
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.
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.