Besides the XULRunner session, we also had a developer tools session at the Mountain View developer day. There was a lot of overlap between the two sessions with respect to development tools. That not really surprising since the technologies used in XULRunner applications and Firefox/Thunderbird extensions are the same. Here is a summary of initial discussion:
- The elusive XUL IDE: Quickly design and preview a XUL UI. Templates for building JS/C++ XPCOM components. Wizards and helpers galore – some people don’t care how to build install.rdf, just that it works.
- Tools for building/bundling extensions: Create manifest and install files. Support easy debug cycles using ‘test’ mode. Create JAR files from extension projects.
- Tools for quality and testing: Extension quality is perceived as Firefox quality so improving extension quality is important. Test frameworks – unit tests and applications tests. Validators for XUL, manifest, install and accessibilty checks.
One of my goals for extension development is that an experienced, but new-to-extensions, developer should be able to create a prototype extension and have it running in Firefox in less than half an hour. That developer should then have all the necessary resources (meaning tools, samples, documentation and support) to turn the prototype extension into a finished product.
These problems are not limited to Mozilla products alone. Songbird, Flock and Komodo all support extensions basically the same way as Firefox.
Sometime in the afternoon, we started a “developer tools” breakout session. We talked about many of the same things from the XULRunner breakout, so we had a good initial foundation.
A XUL IDE may sound good, but would be very hard to get right. Also, developers treat “editors” with a passion. It won’t be easy to get them to switch. Projects like Verbosio aim to provide a extensible framework for editors. It can be a long road, but in this case I have learned a lot from Alex’s efforts. Projects like XUL Booster, which plug into existing editors, Eclipse in this case, may have a better chance of getting used for real development. But even then, not everyone uses Eclipse. A set of applet tools might have a better chance of getting integrated into a variety of editors (like Eclipse, Komodo and Visual Studio), making them more useful.
In addition to the IDE and build/bundling tools, testing tools are important. Mozilla has a few automatic testing methods in use. It might be worthwhile to pull one of those out (mochitest ?) and make it suitable for testing extensions.
Finally, we talked about potential convenience or helper libraries. FUEL is currently waiting for review. We have some common core functionality in place. The next version will likely tackle browser and file IO features. Convenience libraries, like FUEL, will have a significant effect on the productivity of new extension developers. Also, in discussion is an effects-type library for use in Firefox and extensions. Something like we commonly see used in rich DHTML applications, but designed for use in XUL/JS. Think jQuery and Scriptaculous. The effects library was well received, so we might see some movement in that area. We did talk about a widget library, likely in XBL, for newer controls, but interest was much lower.
After all the tool discussion and XULRunner discussion (they overlap so much), I am proposing the following short term “developer tools” plan:
- Create utility applets to provide support for various capabilities, listed above in the first two points.
- Work to integrate those tools into existing IDEs.
- Continue work on convenience libraries like FUEL.
- Plan and prototype some form of an Effects library for XUL/JS.
- Assess the impact on extension development.
As always, feedback welcome.