Do I need a new camera?

It’s been about a year since I last went through this. The result of my last plea for help was a number of recommendations and I ended up buying the excellent Canon Powershot S90. It really is a great point and shoot and I think pretty much exactly what I needed at the time to help me learn a little more about photography. I always figured it would be good test to be able to play with and figure out whether I eventually needed to move onto something more. I guess the main thing that disappoints me a little about the S90 is its slow speed, it can only take about a shot a second in RAW. I often could do with something faster. Also while its low-light performance is better than anything I’ve ever used before it still isn’t as good as I’d like. I could certainly do with a longer optical zoom but that’d have to be combined with something that used faster shutter speeds I guess.

So I’m starting to get a little itch again, fueled by people talking about cameras across twitter all this morning and planning a honeymoon visiting an active volcano in Hawaii. So I’m starting to wonder if its time to look for something more, but I confess I don’t know whether a DSLR is really for me yet. I don’t know enough about lenses to really know what I’d be looking at right now and I’m pretty concerned that I’d just never actually carry a DSLR around enough to make it worthwhile. Micro 4:3 seems like a smaller yet still more powerful option but again I don’t really know what I’m looking at. What actually are the benefits of these over my point and shoot?

So I am asking my good friends of the internet to once again help me out. Should I look for something new or stick with what I have for now? Are there any good books that it might be worth reading to learn more about photography or is a learn-by-doing approach as I’ve been using for now the best way?

What’s next for the Add-ons Manager?

Firefox 4 is just around the corner and it’s great to look back over just how far the Add-ons Manager has come since Firefox 3.6. In fact if you want to see the full history look at my earlier post that shows its evolution since Phoenix 0.2. We set out with some pretty lofty goals for Firefox 4 and I’m pretty excited at just how many of them we achieved. I hope everyone appreciates the hard work that Blair, Boriss, Justin, Henrik, Ben, myself and all the others put in to get us to where we are today.

Of course, we aren’t finished. There were a lot of things that we wanted to get done and didn’t get time for and I’m sure we’ll be getting lots of feedback from users of the final release to work on. Since the pressure has been off I’ve been skimming back over bug reports and notes to try to come up with an idea of what we want to work on over the next few releases of Firefox. As you may know the plan is to move to quarterly releases and not really block a release on any particular projects but we will still be getting an idea of what product drivers will prioritise work on and guess at what other things we can fit in.

UI refinements

In the closing stages of Firefox 4 there were a lot of small polish issues identified. We knocked down a lot of them but there are still plenty of tweaks that we’re going to be bringing to the UI to make sure it is as usable as we can make it. It isn’t really worth applying a fixed schedule to these as they are small one-off fixes that can just come as and when ready. We already have some that are basically ready to land.

Incremental API fixes

There are lots of things that I’d like to see done for the platform and APIs that developers use. Again there is no fixed schedule for these but the main things on my mind are changes that make developing restartless add-ons or extending the add-ons manager easier. I’ve already started work on a couple of these and expect to get them landed after the tree reopens.

Larger projects

There are of course also larger projects that will require more resources. I’ve started writing up short project pages for each of these. Each project should start with the people working on it coming to agreement on what the actual goals should be and an implementation plan so until the projects are actually picked up the project pages are mostly made up. I’ve put down a rough idea of when a project might make it into a Firefox release. These are just guesses, if the project turns out to be larger than expected they’ll come later, if people volunteer to work on projects or if the product drivers decide they are a priority then they could come sooner.

You can see that assuming a quarterly release schedule we have enough projects here to last till the end of 2011 at least, quite likely longer. Over that sort of time I guess it’s almost guaranteed that priorities and plans will change in the meantime but hopefully this gives an idea of what our thinking is at the moment. Expect to see progress on some of the things at the top of the list very soon!

Don’t miss an exciting opportunity to shape the future of Firefox 4!

You might have heard of this web-browser. It’s called Firefox. You may have also heard that a new version is due out soon. As my part in its development I have helped completely reshape the way the add-ons manager looks. The good news is that the large bits of the changes are pretty much done, pretty much all that is left is a bunch of UI tweaks and some small behaviour changes.

This is where you come in. Yes you, the one reading this post. If you have an urge to help out you can look through this list of things we want to get done on the add-ons manager before release, pick one out and go nuts. These are all things that shouldn’t require very much experience working on the add-ons manager or even Firefox in general, though of course some are easier than others. We have some great information about how to get started and also a great community who can help out if you get stuck. So if you’ve ever had a hankering to get involved this would be a great time to dive in.

Once again that list is here: http://bit.ly/duYWdP, give me or Blair a shout if you have questions or don’t know where to get started.

Where is the updated Nightly Tester Tools?

Many of you nightly testers may have noticed that Nightly Tester Tools’ compatibility override feature doesn’t work with the new add-ons manager and may be wondering when I’m planning to issue an update to fix that. The more astute of you may have noticed that there hasn’t actually been a real code update to Nightly Tester Tools in 2 years, barring a couple of simple app compatibility fixes. Those with a sharp memory will remember that I said just under 2 years ago that I was ceasing work on my extensions in my spare time. I suggested that Nightly Tester Tools might still receive the odd update but obviously that hasn’t happened and the truth is that I can’t see it happening anytime soon. I’m too busy with that whole real life thing to even be able to work on projects I do enjoy, let alone maintain old stuff that no longer really interests me.

This unfortunately leaves a sizable number of users losing a feature that they liked and still potentially have a need for. I can only really see a couple of possible roads to follow from here:

  1. Do nothing. Users will be annoyed for a time but eventually find ways around what they needed NTT for.
  2. Find someone else to pick up and maintain NTT. I’ve had numerous requests for the source code for many of my extensions over the past two years, none have ever apparently tried to do anything though. Perhaps someone out there will pick up the torch this time?
  3. Point all the users to something else, like the Add-on Compatibility Reporter (once that is updated to work on trunk). While nothing else I know of works quite like NTT at least something is better than nothing, and ACR has the benefit of being Mozilla supported, provides Mozilla with valuable information about add-on compatibility and may be rolled into Firefox at some point.

Option 3 is the only one available that involves any work on my part but probably the choice that leads to less user annoyance, unless someone reading this wants to take up the challenge or has a better idea?

Update: Part of the Mozilla QA team are going to take over development and maintenance of Nightly Tester Tools, let them know what you want to see!

Time for a new Camera

I’ve never been terribly impressed with my current digital camera. It’s an Olympus FE-280 that I bought on the spur of the moment in Boston a few years ago when my previous camera decided it didn’t want to stay charged any longer. Feature-wise the Olympus probably has almost everything I want, but its menu system is so convoluted that I can never find how to enable the things I’m after in a reasonable amount of time. In the past few years it has slowly developed some bad pixels (both on the view screen itself and on the CCD cell and now the battery charger is starting to flash ominously suggesting that the battery is about to go to a better place so I think it is about time to start looking for a replacement and this time I want to do some research.

Sadly I know probably just enough about taking photos to make me dangerous which means that I occasionally want to do things that probably warrant use of some expensive feature-packed camera. While I would love the power of something like a digital SLR the reality is I would barely make use of all its features and I need something smaller otherwise I will never carry it around with me. But here is a list of the features I am after, maybe someone has suggestions for cameras that have all of these and more?

  • An easy to use mode that does fast exposures
  • Good motion stabilization
  • A way to take a quick sequence of images with one press of the shutter
  • Maybe manual focusing to allow shooting through windows
  • Orientation detection, ideally actually orienting the image file but I guess just putting the EXIF orientation marker is a start
  • I’d sort of love to get RAW images to play around with in the occasion the camera hasn’t been clever enough to work out what I want

Update: So I guess everyone is recommending either one of the Lumix series or the Canon S90. The latter seems to provide more control over shooting at first glance but then the Panasonic site doesn’t offer the full instruction manual for the Lumix cameras, only basic instructions which makes figuring out exactly what you can do with them and how a little more tricky. The Lumix cameras do claim a faster fps in burst mode and all have more zoom than the S90’s relatively paltry 3.8x. I wonder how much use zoom is though when I’m not going to be using a tripod for shooting.

Throwing xpcom docs out into the wild

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.

What is the most useful way to present interface lists?

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?

Improving the API references

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.

Dividing the labour

Faaborg has started a discussion on the newsgroups on the relative importance of polish and blocker bugs (I’d provide a link bug Google Groups seems to be refusing to acknowledge existence of the post). I have been for quite some time now very focused on the in-depth blocker issues, partly because that is where all the interesting work is for me, but also because I think it makes more sense for me or one of the other guys with good understandings of how the extension manager works to be making these changes rather than throwing others in at the deep end.

This has of course left little time for me to fix the trivial issues that Faaborg talks about. The things that users probably notice more and make the product look complete or half-done. This is why I’m really pleased that when I posted a list of simple bugs that anyone should be able to tackle there was a fairly good response. Of the 12 bugs on the original list, 9 have been fixed. I wanted to extend my thanks to those guys that took the time to work on those, some of them probably ended up being a little harder work than anticipated.

Of course the polish list is almost never ending. I’ve been adding more to the list of good first bugs, if anyone is interested in helping out then don’t be afraid to just email me or find me on IRC as Mossop and ask how much work something really involves.

The great bug triage

I was very excited to learn at the Firefox Summit that Rob Strong was handing over ownership of the Extension Manager module to me. He did great work making the extension manager what it is today but has lately had to be more focused on Installer and windows integration issues.

Last week I spent a large part of my time trying to get myself up to speed on all the old filed bugs, clearing out things that clearly aren’t going to happen and trying to consolidate others. In particular I made the effort to go over every single unconfirmed bug and either resolve as appropriate or request any additional information from the reporter. It is rather sad that many of these were issues that noone commented in after the initial report or even worse the reporter responded with additional information but people (including me) dropped the ball and nothing further happened.

This big triage has been quite useful. Firstly the number of unconfirmed bugs for the add-ons manager has dropped from the mid 70s to under 30 (I would give you exact figures and pretty graphs but bugzilla’s charting is broken). I expect it to drop even further next week when I resolve the issues where the reporter is no longer responding to bugmail. Secondly it has allowed me to spot a pattern amongst 6 or so filed bugs which strongly suggests a new issue that can break add-on installations. While I have yet to be able to reproduce it in a test environment I certainly have more information to go on than previously.

Finally I have been marking all the trivial little issues that I think we could fix, but are unlikely to be priorities. These are the kinds of things that if you were interested in helping out and getting started in developing for Mozilla you could start out on. Many will end up being a few lines of patch, just need to figure out where to put it and test it.

So if you are interested in tackling any of these please give it a go. You can find me on IRC (for reasons best left alone I appear as Mossop) or by email if you need any guidance on getting started. I’m going to try to keep this list updated as I find new bugs that fit there, I still have yet to go through all of the 263 confirmed bugs, maybe a job for next week.