One of the Mountain View developer day sessions covered the current state of developing applications with XULRunner. I was hoping that the high density of application developers (Songbird and Flock) and extension developers in the room would help me get a better idea of the pain points involved and a general idea of how to make the situation better. Here is a summary of the session:
- Basic application development is in place: Its easy to use XUL / JS to build a functional application. Applications inherit much of Firefox feature set for free. XPCOM allows code to go native, if needed, but this is harder and not well supported by tools.
- “Fit and Finish” parts are harder: Writing help systems is a little complex (RDF-based) and not supported by tools. Dock / systray and other OS integration features are missing (patches exist for some). Software update of your application is not easy and not supported by simple tools. Shared runtime is not ready yet and may never be a bulletproof system.
- Development tools & documentation are sparse or missing: XUL IDEs are immature at best and may not be the “holy grail” anyway. DOM Inspector and Venkman are difficult to integrate into development process, but would be a huge benefit. Validation and syntax checks on XUL, preferences, manifests, install.rdf and app.ini would be a great help. Unit testing and UI testing tools are missing.
After lunch, we created some breakout sessions and developing with XULRunner was one of the sessions. We traded development experiences and talked about what could be done to make XULRunner development better and more complete. Here are some things we came up with:
- Pull together a list of bugs/features that would be most beneficial to XULRunner so contributors would know where to focus efforts.
- RDF is an obstacle to new XUL developers and the new XML \ SQL based XUL templates could be easier to learn. Those backends should be in Gecko 1.9 and documentation and samples would be beneficial.
- Software updates are an important application feature. The current MAR system is getting better documentation, but tools to simplify the process of creating MAR files, updates.xml and automatic updates servers would be very helpful.
- Enabling DOM Inspector and Venkman for debugging XULRunner applications would be a great thing. Making it as easy as adding a commandline switch, -inspector or -venkman, would greatly improve the development cycle for XUL applications.
- Debug tracing and logging for merging overlays, registering component and chrome, and XUL entity problems. Currently, you get little or no feedback as to the reason for failures.
- Tools and documents for creating application help that works with the Firefox help viewer. The help system uses RDF, which makes it harder than it chould be. Tools would simplify the process greatly.
- Better OS integration including dock/systray support, window alpha support and other stuff (Songbird devs had a list).
- Stronger community around XULRunner including more documents and samples on MDC, stronger community involvement in IRC channels and perhaps a dedicated newsgroup.
I’d like to see more community “grow up” around XULRunner. Many of the items on the list could be addressed by a community. Some items could not and I am looking into what it would take to address them. The good news seems to be that most, if not all, of the Mozilla oriented items are active.
I believe that the breadth and richness of the Mozilla platform surpasses that of Apollo and WPF/E, but developer support needs some attention. I also believe that many of the developer oriented improvements listed here have equal benefit for extension development too. I am interested in other XULRunner development feedback, so please comment.
Here’s a somewhat different take:
http://jinsync.com/?q=node/12
For my XULRunner work the tracing and logging would be helpful. DI and Venkman would be a godsend – although Firebug would be even better 😉
I’d also like to see a smaller XULRunner deployment set. A 12MB Windows build does not compare favourably against a download of Firefox, but it’s often harder to get a web browser deployed in the workplace than a “framework”. Perhaps we need a developer build, loaded up with goodies, and a smaller release build for final deployment.
I would like to figure out how to do a simplething like reading from the file system and presenting thumbnail file ‘links’ as simple (and crappy) as Windows Explorer does it.
My attempts thus far have proven fruitless. Can anyone help or am I banging my head against a limitation of XULrunner?
Generally speaking I agree there seems to be a lack of a community for XUL. Addressing that should be a Mozilla thing. Do what you do well – make up some fancy community marketing scheme to generate interest.
Simple things would also help like updated documentation. As recently as Jan/Feb this year I had to hunt through XULplanet and/or MDC to try and find the most accurate/recent version of any particular document. Not good enough.
Are newsgroups really still a good solution? Surely they are not as accessible as a web based forum? Why doesn’t MoFoCo just bust out phpBB and start an XUL forum?
@mark : in france, there is already a xulrunner community, because more and more companies use xulrunner for there internal application 😉
> I believe that the breadth and richness of the Mozilla platform surpasses that of Apollo and WPF/E, but developer support needs some attention.
I’m totally agree with you ! XulRunner is a fantastic platform, but needs improvements NOW. Many french developers are interested by XulRunner, but some of them hesitate to use it because of lacks you have listed. That’s a shame.
@pd: There is already forums wher you can ask questions, at mozillazine.org, xulplanet.com, and for those who speaks french, at xulfr.org.
I agree that XULRunner is a very good product, but I think that it would need more documentation support: now you start using it and you feel like a pioneer, even if the platform looks very stable. I think that XUL is nice too, but not as flexible as it could be. For example I hit the problem of not being able to change the background color of a textbox without changing completely the style (I wanted to use the native theme and change the background, it seems not to be possible).
My impression is that XAML is doing a better job than XUL, it is more flexible and “coherent”. For example, imagine to be a new developer, and you are not a web developer: in order to be able to create a UI and personalize it a bit, you need to learn XUL and CSS, that are two completely different languages, different syntax, etc. With XAML, albeit complex, you have just one underlying language to do everything, UI description, styling, triggers, and so on.
On documentation side it is difficult, sometimes, to understand how to change some basic property, because the docs seem to assume that you already know CSS well enough. Sometimes I’ve got the feeling that I’d be better off using HTML to do the UI, instead of XUL.
Also RDF is really the mysterious piece for me: I did not have time to learn it. It would be good to have a version of “RAD with Mozilla” that is XUL centered, because that book is really saving me a lot of time, even if it speaks about Mozilla. BTW, think that I’ve been using XUL for a short period and only in my little free time.
> I would like to figure out how to do a simplething like reading from the file
> system and presenting thumbnail file ‘links’ as simple (and crappy) as Windows Explorer
> does it.
pd, you can do this by appending ‘moz-icon:’ to a file url.
For instance:
where size is 16 or 32.
See http://lxr.mozilla.org/mozilla/source/modules/libpr0n/decoders/icon/nsIIconURI.idl for some info.
Thanks for the top Neil, very appreciated.
Unfortunately though it’s probably a good example of a weakness in XUL. I really don’t want to criticise your tip but more illustrate the problem:
I think this sort of thing should be easier than reading through source code for an component of the system.
I really don’t understand what nsI means as the prefix for all these component calls, let alone know how to read the component source to decipher what I need to do.
Apologies if I am just being lazy.
For what it’s worth I really like where http://xulbooster.org is going with the ‘plugins’ (is that the correct term?) for Eclipse. I think that is the best way to go. I don’t understand why an XUL IDE is apparently a controversial subject. Can someone please shed some light on that?
XULRunner needs to be in Firefox 3.
@riccardo: yours is a good point about non-HTML developers not being able to tweak elementary properties without knowing CSS.
I’m the opposite in that I come from a HTML/CSS background and have moved to Perl/PostgreSQL/JavaScript and some PHP tweaking. However I still have problems doing elementary things with XUL.
Is it just me or is XUL foreign to desktop developers with no web experience but also foreign to developers of interactive web sites without strong JavaScript?
I’ve toyed with JavaScript but – like I suspect a lot of web developers – only ever one or two functions at a time for specific minor tasks. When it comes to important widgets of a rich application nature, I tend to beg, borrow and re-purpose anything available.
When I have sat down to try some serious JavaScript for an extension, I am intimidated by verbose and foreign XPCOM calls.
Mark and John Resig looked like they were going to solve this with http://wiki.mozilla.org/FUEL but the 0.1 release is now a month overdue and I don’t see a download link on that wiki.
How is progress on FUEL Mark?
I’ve been wondering, does XULRunner support progressive enhancement?
What’s great about Apollo is that I can copy the app.xml and just start writing a HTML/CSS DOM/JS web-style app, but then progressively enhance my app with Flex components. Can that be done with XUL?
Also, I’m going to suggest that names are a powerful thing.
People don’t say they’re going to build webapps with MXML, they say they’re going to use Apollo, Flex, or Flash.
I’m not sure what they’ll say about XAML, but maybe they’ll say Visual Studio or Expression Blend.
When you say Mozilla, you think of the browser, not of the platform, and XUL doesn’t quite ring a bell for many. Thoughts? What is the open app-platform built on top of Gecko/XUL called?
Ideas from http://en.wikipedia.org/wiki/Gecko
“Gargoyle”
“Tokay”
Pokemon-inspired:
“Treecko”
Geckomon
Kimori
Juptile
Blink, Beast (from the Book of Mozilla)
Mozko — Moz(illa/Gec)ko
Of these, I vote for “Mozko” or “Beast” 🙂
~L
Is there a good tutorial which teaches you how to build XULRunner based apps (for the UI layer) and native code for the core processing? I’ve been wanting to do something like this for such a long time but so far I have only managed to find tutorials and documentation on how to build XUL+JS based FF extensions. Folks at Songbird and Joost seem to have figured this out.
I would really appreciate it if you could point me to some good tutorial or even better if you could write a quick post on this blog!