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.