Month: March 2007

Saving Canvas to a File: Given a canvas element and a destinstion file path, this code snippet saves the contents of the canvas to a PNG file. The code could easily be tweaked to become a general purpose “download to file” instead of only handling canvas elements.

XUL Control Guide: This is a handy quick guide to the various XUL control elements. In addition to a picture of the control, there are also links to reference and tutorial information.

Troubleshooting XPCOM Registration: When component registration fails its currently very difficult to figure out the cause. This article steps through a few troubleshooting tips you can use to find the problem. We hope to get better tracing and debugging of component registration failures in Firefox 3.

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.

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.

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.

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.

The Mountain View Developer Day was a blast. We covered a lot of topics. A great bunch of people showed up and the high level of crowd participation helped out a lot. The Songbird and Flock folks gave lots of good feedback regarding their development experiences. More on that later. A quick recap of the lightning topics:

Mozilla Labs – Basil Hashem: Basil did a good job framing the Mozilla Labs mission. He also showed demos of 2 recent Lab projects – Joey and The Coop.

Writing Reftest – David Baron: David gave a brief update on how and where Mozilla is using more automated testing. He then gave us a short how-to on creating a reftest, which can be used to verify behavior of visual layouts. For info on reftests check out this MDC article.

UI Heuristics – Alex Faaborg: Alex presented some guidelines for making a good UI and related the guidelines to parts of the Firefox UI. Yes, he showed good and not so good examples. We talked after and I am hoping we can get a set of UI guidelines for extension developers.

3D extensions to <canvas> – Vlad VukiÄ‡eviÄ‡: Vlad showed a quick demo of an extension that adds 3D capabilities to <canvas>. Using JavaScript, he loaded a 3D model into the enhanced <canvas> and was able to pan, rotate and zoom around. It was pretty cool and refresh speed was fairly crisp. I hope to see more from Vlad on this extension and demo.

Buildbot Patch Server – Rob Helmer: Rob showed off some features of the buildbot “try” system, modified for use with Mozilla (part of Ben Hearsum’s buildbot work). The system takes patches and start builds. This allows developers to test patches on various OSes and hardware, increasing the quality of the patch.

After the lightning sessions, we planned a few breakout sessions. We ended up doing sessions on XULRunner development, 3D graphics in the Browser, Extension development tools and The Coop. I have notes on the XULRunner and Development tools sessions. I’ll get some blog posts on those sessions soon. I also have some pictures I’ll upload shortly. Lastly, I’ll check with the other presenters to see if they have notes or information they can post about their sessions.

We have the schedules for both Mountain View and BostonDeveloper Days up on the wiki. We are planning some short, fast ‘lightning’ talks on various topics. The lightning talks should give the group a broad view of different projects and experiences. Afterward, we plan on breaking out into longer discussions or hacking sessions based on the groups interests.

I just read Jeff Atwood’s Are Web Interfaces “Good Enough”? post. He explores why web (RIA) versions of desktop applications are “less satisfying” than the desktop versions. He makes some good points and I’d like to build on his post. I see it the other way around: Web versions have less bloat than desktop versions. Let’s state the obvious right up front: I am talking about good desktop and good web applications. You’ll find crappy versions of both.

Desktop applications have a tendency to go overboard with features and gold plating (bloatware) – trying to use every native UI widget/feature possible. They have to, because after the first or second version, the application has likely jumped the shark. The only way to keep people buying it is to upgrade the UI or add wizzy ways of executing commands (which already had a non-wizzy way). Desktop applications are released, deployed and installed less often. Deploying desktop software isn’t cheap.

Web applications have to work with less, which in most cases means the application has to focus on the problem at hand. Strong focus is a good thing. Web applications are cross platform and have a further reach than a desktop application. Web application are easier to upgrade and release.

What we are seeing today is a shift from desktop to web-based applications. For the majority of users (if your reading this, I am not talking about you) the ease and reach of a web-based applications is outweighing the lack of non-value add features. Even Jeff admits that he was able to do everything he needed with the web application. Do normal users have the “fit and finish” issues that developers have?

This trend will continue as browsers begin to enablemorevalue add features, such as rendering, storage, and offline support. The trend is also why technologies like XULRunner and Apollo are interesting: Ways to create web-ish desktop applications.

Offline cache support was added to the Firefox trunk last night. Check out bug 367447 for details. This is a major step in Firefox 3’s offline webapp support. There is still some more things to add, however, including an API for web developers. I’d expect the API to “feel” like some of the WHATWG APIs for web applications. I’d also expect drafts of any APIs to be ready for review soon. In fact, bug 371432 does have some API discussion.

The Mountain View Developer Day is approaching (Mar 25th). Looks like we’re getting a nice mix of people and interests. Since Mozilla is such a distributed company, its good to get together and be in the same room. I am looking forward to that.

If your interested, there is still time to signup. Checkout the proposed topics and add more to it. The 3D canvas stuff looks particularly interesting. It should play into webapp (RIA) discussions and how Mozilla can evolve to support them.

I have been using the prototype WebRunner for a few days to access GMail and Zimbra. Overall, I am quite happy with the results. The webapps load fast and I like having them appear in my ALT+TAB list. I am using Firefox for browsing and not running webapps, which feels better too. Firefox stays snappy and I have not had to “kill” its process because of speed or hung webapp problems.

Of course there are things I miss when using WebRunner. Most notably:

Support for popup windows – Zimbra in particular uses (my preference) a popup to compose email.

Support for inline spell checking – Some webapps do have their own spellcheck support, but I really love Firefox’s system.

Support for float-over link destinations in the statusbar – Yes, I like to see where I am going if I click that link.

Support for a context menu – I use it infrequently, but I must use it enough to feel weird when its not there.

Adding support for popups turned out to be a 1-line preference fix. I learned about nsIXULBrowserWindow to get the link info in the statusbar. I updated the prototype for those of you playing at home:

The usual answer involves loading the HTML into a hidden iframe, which requires a DOMWindow. Or potentially using the SAXParser that appeared in Firefox 2, though you don’t get a DOM that way.

Thankfully, the answer is going to be a lot easier in the next release. Rob Sayre has a patch for parsing “text/html” using the existing DOMParser API. Currently, DOMParser only handles “text/xml”, hence the warning at the top of the MDC page. This limits its usefulness given the lack of XHTML in the wild. The new feature will make it very easy to load HTML (even partial tags) into a DOM.