sdk on Oxymoronical

Developer Tools meet-up in Portland

Wed, 05 Mar 2014 14:33:06 +0000

Two weeks ago the developer tools teams and a few others met in the Portland office for a very successful week of discussions and hacking. The first day was about setting the stage for the week and working out what everyone was going to work on. Dave Camp kicked us off with a review of the last six months in developer tools and talked about what is going to be important for us to focus on in 2014. We then had a little more in-depth information from each of the teams. After lunch a set of lightning talks went over some projects and ideas that people had been working on recently.

Firefox now ships with the add-on SDK

Wed, 15 May 2013 15:31:59 +0000

It’s been a long ride but we can finally say it. This week Firefox 21 shipped and it includes the add-on SDK modules.

What does this mean? Well for users it means two important things:

Smaller add-ons. Since they no longer need to ship the APIs themselves add-ons only have to include the unique code that makes them special. That’s something like a 65% file-size saving for the most popular SDK based add-ons, probably more for simpler add-ons.
Add-ons will stay compatible with Firefox for longer. We can evolve the modules in Firefox that add-ons use so that most of the time when changes happen to Firefox the modules seamlessly shift to keep working. There are still some cases where that might be impossible (when a core feature is dropped from Firefox for example) but hopefully those should be rare.

To take advantage of these benefits add-ons have to be repacked with a recent version of the SDK. We’re working on a plan to do that automatically for existing add-ons where possible but developers who want to get the benefits right now can just repack their add-ons themselves using SDK 1.14 and using cfx xpi --strip-sdk, or using the next release of the SDK, 1.15 which will do that by default.

The Add-on SDK is now in Firefox

Fri, 01 Feb 2013 22:06:43 +0000

We’re now a big step closer to shipping the SDK APIs with Firefox and other apps, we’ve uplifted the SDK code from our git repository to mozilla-inbound and assuming it sticks we will be on the trains for releasing. We’ll be doing weekly uplifts to keep the code in mozilla-central current.

What’s changed?

Not a lot yet. Existing add-ons and add-ons built with the current version of the SDK still use their own versions of the APIs from their XPIs. Add-ons built with the next version of the SDK may start to try to use the APIs in Firefox in preference to those shipped with the XPI and then a future version will only use those in Firefox. We’re also talking about the possibility of making Firefox override the APIs in any SDK based add-on and use the shipped ones automatically so the add-on author wouldn’t need to do anything.

Throwing xpcom docs out into the wild

Tue, 19 Jan 2010 19:50:41 +0000

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.

Bumper XULRunner release day!

Wed, 22 Jul 2009 18:42:41 +0000

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.

Where is XULRunner 1.9.1?

Wed, 08 Jul 2009 19:49:04 +0000

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.

Moar xpcom docs!

Sun, 05 Jul 2009 17:57:03 +0000

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.

XULRunner 1.9.2a1pre builds also available

Sat, 28 Mar 2009 01:23:34 +0000

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

XULRunner 1.9.1b3 builds, get them while they're hot

Fri, 27 Mar 2009 18:20:49 +0000

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.

Updated Interface lists

Thu, 29 Jan 2009 17:27:08 +0000

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.

What is the most useful way to present interface lists?

Mon, 01 Dec 2008 22:30:51 +0000

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:

Improving the API references

Sun, 16 Nov 2008 13:21:01 +0000

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.

API reference updates

Sat, 15 Nov 2008 20:29:20 +0000

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.

Finding API Changes

Fri, 24 Oct 2008 20:07:51 +0000

I started a small discussion on the newsgroups the other day wondering about the numbers of API changes that had landed on trunk since 1.9.0. It was a short discussion, maybe partly because all I had to go on were the vague metrics that mercurial could give me. It also evolved a little into a discussion of how add-on developers we’re meant to find out about API changes. It’s true that as developers we are getting better at trying to announce our changes as much as possible, but inevitably we miss some, and if you don’t track the announcements what then?

Why 2 SDKs are better than 1

Thu, 10 Apr 2008 19:30:42 +0000

In the past the Gecko SDK was somewhat limited. You could compile against it, but only if you were using frozen components, of which there are exceptionally few. You can build an application with only them, but I’d be startled if any moderately complicated app or extension gets by with only them. Thankfully this has changed for 1.9 and the new style SDK contains all interfaces and headers, frozen and unfrozen. This gives you access to lots more, though has the minor disadvantage that you have to keep an eye on what you are using as it could break in the future.

Mac Intel Gecko SDK

Sun, 13 May 2007 22:38:37 +0000

Update: Mozilla now produce intel gecko SDKs so there is no need to use the version I have put here, I’ll leave it for posterity though.

It’s currently a bit of a pain building xpcom components in intel macs. The only officially available sdk is ppc only. Until Mozilla come up with an official version, here is an intel build of it for those that want it: gecko-sdk-mac-intel-1.8.1.3.zip

As the name suggests it’s built against Gecko 1.8.1.3. To the best of my knowledge it’s right but please don’t bug me if you can’t get your component to work with it unless you’re pretty positive that it’s the sdk that’s wrong.