Oxymoronical

It’s been quite some time since I last worked on my prototype XPCOM component/interface viewer and I have to face facts, it’s likely to be quite some time till I do again. I haven’t even had time to update it with the data from the latest 1.9.2 and trunk interfaces. Since I’m not likely to go anywhere else with this I’d love for someone else who thinks it is worthwhile to pick it up and run with it. I’ve just done a final commit adding a README on how to use the code (though I’m sure it is lacking in key ways so be prepared to have to experiment a bit) and the full source is available in my hg repository. The code is MPL tri-licensed so you should just be able to fork and go do your own thing. I should be able to answer any questions and would love to see it get finished and really usable somewhere.

Thanks to the hard work of Nick Thomas and Lukas Blakk, today I can announce the availability of two new official releases of the XULRunner runtime and SDKs. XULRunner 1.9.0.12 is a maintenance release for the 1.9.0 branch (the code that matches Firefox 3.0.x). XULRunner 1.9.1 is the first official release of XULRunner on the 1.9.1 branch (which matches the code in Firefox 3.5.x). Unfortunately we’re not quite at the point of shipping XULRunner releases at the same time as Firefox 3.5.x releases, but we should have a 1.9.1.1 release soon.

• XULRunner 1.9.0.12 (release notes)
  • Windows runtime
  • Mac OSX runtime
  • Linux runtime
  • Gecko SDK
  • Source code
• XULRunner 1.9.1(release notes)
  • Windows runtime
  • Mac OSX runtime
  • Linux runtime
  • Gecko SDK
  • Source code

A question I have been hearing quite a bit on IRC since Firefox 3.5 was released. We don’t quite have the build automation set up to do XULRunner 1.9.1 releases at the same time as Firefox yet, but Nick has been awesome and manually spun some release candidates. These should be pretty much good to go but it would be useful if anyone interested could try them out and report on any serious problems they see. Either just comment here or file a bug and mark it blocking bug 502915.

Without further rambling go get the release candidates.

While many of you were out blowing things up over the weekend I spent a few days varying between getting quite a bit done and banging my head against my desk in frustration.

First I updated the XPCOM interface lists that I have been working on with the final release version of Gecko 1.9.0. A few people had asked me for it but I had hit upon the problem that I had lost some of the arcane scripts that I was using to gather the data and so I had to rebuild them first. I have dropped information about the beta versions of 1.9.1 now, just because it was less work that way, if people desperately want them back then I can probably do it.

Secondly I finally sat down and put some hard graft into my rewrite of the project. Some time ago I decided on what extra information I could easily find out automatically and wrote the new code to shove it all into a database. It took till this weekend for me to actually write the web front-end to it. Despite appearances it is actually a complete rewrite. Previously I was using hand-rolled database access code in php. The new version is based on Django which is apparently what all the cool kids are using these days. I was for the most part pleasantly surprised by Django, it makes quite a lot of things significantly easier, but it does suffer from the problem that most object mappers do, it never quite does exactly what you want (or expect). Still I’ve no doubt despite the teething problems I found I have got further like this than I would have by hand. Pro-tip to those thinking of using it, don’t trust it to be right when it tells you what line of a template is causing an error.

Not everything is implemented yet, and I’m sure there are a few bugs laying around to find, but you can take a sneak peek at it. This is what is new:

• Lists components as well as interfaces
• Shows what operating systems interfaces are available on (watch out, this can and does vary with the version of Firefox)
• Shows what components implement a particular interface (again, can and does change with the Firefox version)
• Shows what interfaces a component implements and for which platform (ditto, our platform is complicated ok?)

There is actually a lot more potential information that could go into the database, including listing for multiple applications, but I think the UI will probably not develop that much further, the additional information would just make things far to complicated to understand.

Just as I’ve made some 1.9.1b3 builds I’ve spun some builds based on the latest trunk. Feel free to use these to see how things are shaping up with the bleeding edge Mozilla code. Obviously it is pre-alpha so not for productions.

• Windows runtime sdk
• Linux runtime sdk
• Mac OSX universal runtime i386 sdk ppc sdk

In the process of switching from CVS to Mercurial (and behind the scenes Tinderbox to Buildbot), quite a lot of Mozilla’s build and release systems have had to be updated. Sadly one of the casualties that has yet to be resuscitated are nightly builds of XULRunner on the 1.9.1 branch and trunk. Catlee is now doing some excellent work to get these up and running, but until that gets going here are some semi-official builds using the code matching Firefox 3.1b3. I say semi-official, they were built on regular build slaves using the standard configuration, but just done by hand. I also haven’t tested all of them yet so let me know if you hit any issues, they might be good indicators of issues we’ll see with the nightlies.

• Windows runtime sdk
• Linux runtime sdk
• Mac OSX universal runtime i386 sdk ppc sdk

I’ve generated a new database for my interface listing webapp so you can now see the current state of the 1.9.1b3pre and 1.9.2a1pre platforms. So for all you extension developers getting ready for the Firefox 3.1b3 release maybe you want to see what has changed since 3.1b2? Or since 3.0?

There are still more things I want to do with this web-app, but right now my time is being spent elsewhere so for now I’ll just keep it up to date with the beta releases. Once 3.1 final is released I’ll likely remove all the beta versions since they probably won’t be necessary then.

I have for the time being had to disable caching in the application, it was eating up literally gigabytes of disk space on my web server and not giving all that much of a speed-up.

I’ve just rolled out a small update to the interface cross reference, nothing major, just fixing a few bugs and I’ve put up what looks like the final set of interfaces for 1.9.1b2.

I’ve now figured out the best way to gather the interface lists and so the cross reference now includes all interfaces used in all 3 major platforms of Firefox. It is relatively simple for me to add the interfaces for other applications now but this got me thinking about what kind of uses people are making of this and how the multi-OS, multi-app interfaces should be presented. A few ideas came to mind:

• App developers probably just want to see the interfaces in their app, either only those that appear for all operating systems or those for a specific OS in some cases.
• Add-on developers probably want to see some kind of shared set of interfaces (what you might call gecko/toolkit) that appear for all apps they are targeting, unfortunately this changes depending on the set of apps. Again they probably want for all OS or for a specific OS.
• Maybe I shouldn’t even bother doing anything and just include a note in the interface display about where the interface actually exists.

I’m sure other people have other ideas of how it might work, any suggestions?

I forgot to add to my last post some information about what I currently had in mind to improve about the API reference I’ve been working on. Any further suggestions people have are very welcome, but here is the current few ideas I have.

Currently it only indexes Firefox and Gecko interfaces, in fact it only indexes those used by an OSX build of Firefox. It would be nice to be able to index interfaces for all the main applications and for all the platforms. There are a couple of issues with this. Firstly I’d want the UI to work so people viewing it could select what set of interfaces they wanted to see. Secondly actually building the lists of interfaces for each application and OS is going to be pretty tricky I think. So far I’ve resorted to building Firefox then looking in dist/idl. This works but it is time consuming. Possibly I might be able to come up with some clever nonsense to make the build system only compile idls but we’ll see.

It would be nice to be able to include a list of the component contract ids available in the platform and what interfaces they implement. This is I think pretty difficult to do just by parsing the source files. Potentially a little extension could run in the app and do some looking through Components.classes to find this out. One issue here though is there is no way to tell whether components are services or not so instantiating them is potentially problematic. This is a problem that could be solved by brute force, or maybe doing a special instrumented build.

So those are my main two ideas, if anyone has any suggestions on how to make those tasks easier or for other things that should be there then shout them out.

Since my first announcement about my little api reference tool I’ve slowly been working on updates to make it more useful and easier to navigate around. I’ve now gone and pushed the latest version live. A few of the new features:

• The main and platform lists of interfaces are split by the module where the interface lives.
• Interface lists have a quick filter box, type in it to filter the list quickly.
• Any interfaces used as return types or parameters are now links to get you straight to the information about them.
• Full IDL support so it now lists all the special attributes and for the uninitiated they have tooltips that explain what they mean.
• You can now list all usage of an interface by other interfaces.
• Constants are ordered the same as in the source IDL since they tend to make more sense that way.
• Includes direct links to the source IDL file.

I’ve also updated the database with the latest APIs in 1.9.1b2pre and as soon as 1.9.1b2 is frozen I’ll update it again just to be sure it has the latest versions.

You can also search the API for interfaces. There isn’t any UI for this right now but it is perfectly set up for a smart bookmark. Just use http://www.oxymoronical.com/experiments/apidocs/search/interface/%s for the url and an appropriate keyword and you can do quick searches for substrings of the interface name.