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.
- Develop libraries to increase productivity: FUEL – convenience JavaScript wrapper for core XPCOM functionality. Effects (?) – bringing DHTML effects into chrome. Widgets (?) – bringing newer RIA widgets into chrome.
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.
The Breakout
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.
I would really like to see the application of JavaScript libraries to XUL/JS. Take Prototype’s API for example, it’s insanely useful
Enumerablemethods are really useful for XUL/JS development, especiallypluck(), which “plucks” an attribute from an array of objects and returns them in an array, andinvoke(), which calls a method of every object in an array and returns an array of whatever the methods return for the objects.We, at xulfr.org, have contacts with XulBooster’s author (he’s french 🙂 ). We will discuss with him to improve xulbooster for xulrunner app.
Paul Rouget (from Xulfr staff), develop a plugin which embed scintilla editor. I saw it (it’s not available for the public for the moment), and it will be a good start for an IDE based on xulrunner. You can read post about it : http://blog.mozbox.org/tag/codeeditor
You talk about FUEL. This is a great project. But i don’t understand why there isn’t a will to put it into the toolkit, instead of into the browser package. The result : we can’t have FUEL into xulrunner app, although many of FUEL objects could be very usefull.
FUEL is really exciting.
The notion that developers are religious about their editors and therefore are less likely to ‘switch’ to an IDE is, for me, false logic. Surely one of the aims of XUL is to bring quasi-developers into desktop app development? I’m talking about those whose guilty pleasure might be Dreamweaver or those who are hand coders and can’t be rooted stuffing around with anything but a quick drag and drop interface builder.
Who says that developers are limited to one tool?
The sort of developers who are religious about their tools are surely the sort of developers who are that far advanced, they don’t need all that much help with XUL anyway?
Or perhaps all that is false logic on my behalf ?
However I see no reason why all the work being done on XUL – as disjointed as it is – cannot be harnessed and built into a much more effective development platform.
Oh wait, Mozilla doesn’t really care enough about XUL, that’s the reason!
Why not just use and existing IDE and add to it? Komodo provides an IDE (and a free Edit version) that already supports most of what is needed for extension development:
* provides project templates for managing extensions (project structure, rdf, jar and zip features)
* provides completions and calltips for XUL, JavaScript.
Then add to it, since it’s based on Mozilla itself, you create extensions (or macros) for Komodo, to add other features like:
* previewing XUL
* XUL WYSIWYG editor
Most of the work is done already.
Note: I have a slightly biased view as I work/develop on Komodo itself at ActiveState 🙂
Cheers,
Todd
Laurentj – I know about Paul’s work and I am eagerly awaiting it’s release. The editor plugin will be a great addition to extension/xulrunner developers. FUEL is not being strictly tied to Firefox. Firefox is just the best initial application to focus. The generality of XR applications makes it harder to focus FUEL requirements. Simplifying Firefox extension development is also one of the main objectives of the library.
pd – FUEL is being reviewed at this moment (I was told on IRC). We (John & I) expect to have a few iterations of changes, but it should land soon, unless we really messed something up. Also, moving people from DeamWeaver or Visual Studio to a yet to be built XUL IDE is not only false logic, but a false hope. I don’t plan on wasting whatever effort we have on a false hope. I do believe that creating a package of tools/applets that can integrate into existing IDEs are the best hope in the short to mid term.
Todd – That is exactly the plan. Build tools/applets (or extensions in the case of Komodo) that we can leverage across multiple IDEs. I’ll probably be asking for help from you guys 🙂