Among the more common issues that have had people grousing over the years is that Firefox doesn’t use the Mac OS X keychain to save login information (plus the equivalent gripe on Linux).  For most users this isn’t really that big a deal, but admittedly the fact that keychains can be synchronized across computers if you’re a .Mac user has its appeal.

Firefox 3′s new Login Manager provides the nsILoginManagerStorage interface, which you can implement to provide a replacement login information storage model for Firefox.

We now have documentation for how to do this sort of thing.  Enjoy!

 

I’ve been continuing to make my way through the dev-doc-needed and Documentation Requests lists in Bugzilla for the past week.  I knocked four or five bugs off today.  None of them were huge, but it was still very satisfying.  It’s a great feeling to be at a point in the documentation work that I can be focusing on the little things.  Makes me feel like I’ve really accomplished something worthwhile.

In particular, the dev-doc-needed list is down to 17 bugs (or was when I looked at it earlier this evening).

I’m really pleased with the developer documentation for Firefox 3.   There are of course still things that could be better, but by and large, we’re in great shape.  I’m happy that we’ve been able to continue to improve upon the progress we made during the Firefox 2 development period.  Firefox 2 was the first release of Firefox to have essentially complete documentation by the time it shipped.  Firefox 3 had essentially complete documentation early in the beta cycle.  That’s fantastic progress, and I’m very excited to be a part of it!

 

We have several ways to get documentation issues taken care of on the Mozilla project.  You can tag an existing bug with the “dev-doc-needed” keyword to let the writers know that there’s something in that bug that will require a documentation change.

You can also file a bug against the Mozilla Developer Center product.

These are great ways to get major issues queued up to have someone take a look at them, and I strongly encourage people to use them.

But try to consider this when filing a bug, or tagging it for documentation needed: How long would it take you to edit the documentation yourself?  Often, the documentation bugs come down to just a few minor edits.  Maybe adding a note saying that a feature was deprecated in Firefox version X, or a note that a particular behavior changed.  It would take the engineer that made the change less time to edit our wiki to reflect the change than it does to file a bug on it.

This is especially important when you consider this: the writers don’t necessarily know the ins and outs of the code you’re working on.  All too often, I settle in to research a documentation bug and spend many hours reading the bug, reviewing the code, and so forth, only to discover that it comes down to a one or two line change to the documentation.

Probably 80% of the bugs marked as “dev-doc-needed” are like this.  I spend an average of two hours on each of these, and most of them are extremely minor edits to the documentation when you get down to it.

Worried about your writing?  Don’t!  We have wiki gnomes that clean up things like that, and it’s a lot faster to tidy up a hurriedly-written documentation update than to do it from scratch!

If you’re totally wiki-phobic, at least add a comment to the bug that specifically lays out what the issue is that needs to be addressed.  Most of the “dev-doc-needed” bugs don’t have anything in them that says what actually requires a documentation edit, which winds up requiring me to read sometimes dozens of comments that are often cryptic, then ask a lot of annoying questions, only to again find out that the edit needed is very small.

So when you submit a bug against docs or mark a bug as “dev-doc-needed” — please take a moment to think: can I fix this myself?  If not, please add a comment to the bug laying out specifically what needs to be documented.  That will help keep me from going completely insane, and we all know what kind of documentation gets written by insane people.

 

I have the “Kit” Mozilla Developer Center desktop on the main screen on my iMac here at home.  My daughter likes to come in and ask me to move windows out of the way so she can see and talk to the “Firebox.”  She also likes me to have iTunes play some of her favorite songs so she can pretend the Firebox is singing to her.  It’s hilariously cute!

 

The very first thing that’s important to note about this beta release of the iPhone SDK is that there’s currently no Interface Builder support, despite it being talked up at the demo yesterday.  This is a pretty serious blow to ease of development at this early stage.  Instead of simply dragging and dropping interface elements onto a form, you have to programmatically instantiate UI objects and place them into your view.

That’s not disastrously bad or anything, just frustrating; after using IB for so long, having to go without it sort of sucks.

The API is pretty well thought out.  It makes use of much of the Cocoa API we already know and love, with a new UIKit that provides the UI elements instead of using NSWindow, NSView, and so forth.  Instead, we have UIWindow, UIView, etc.  They work very similarly, except they’ve been tuned for the iPhone.

It didn’t take me too long at all to create my first “Hello world” application, which is good.

On the down side, the documentation is a bit of a mess at the moment; when you go to the “iPhone OS” documentation, you get a lot of links back into the Mac OS X documentation, and much of that material is almost — but not quite — accurate for the iPhone OS.  Obviously the writers have a little work left to do there.

It’s not in bad shape for a beta, though (aside from the missing IB support thing).

There are some nice APIs for things like tracking touches on the screen, monitoring the accelerometer (you simply register to receive notifications of accelerometer events, and a delegate gets called as the user tips the device), and so forth.

Video playback is supported but only in full-screen mode.  That’s not a tragedy, but it’s a mild bummer.

Audio playback has both support for short sounds (five seconds or less) and for streaming audio files off  the flash storage (but only one at a time).  That’s more than adequate for any use cases that I can legitimately think of.  It also supports 3D positioning of audio, audio recording, and streaming audio over CFNetwork connections.  Excellent.

Handling rotation of your view is as simple as using a view controller and having it accept a call that notifies it that the display has rotated.

Generally the API is quite refined from a first glance, and looks like a lot of solid thought went into it.  I look forward to being able to do some real work with it to see what I can do.

The “Aspen Simulator,” which lets you test your code on your Macintosh, is a bare-bones iPhone simulator.  It has Safari, Photos, Contacts, and Settings apps on it, but otherwise doesn’t have the apps an iPhone normally has.  When you create your iPhone project, it defaults to running on the Simulator.  To test, all you do is Command-R to run it, and the Simulator launches and automatically starts up your app.  There are menu options that let you rotate the device left and right, and you can simulate pinching (two-finger) touch events by holding down the Option key while clicking and dragging on the touch screen.

Debugging works great as well.  If you choose to run in debug mode, it works just like you’d expect. Single-stepping, tracing, watching variables, and so forth all work exactly like they do when debugging a Mac application, right within Xcode.

There are a couple of disappointments.  The lack of IB is (have I mentioned this before) a real bummer.  The fact that it’s a beta is a bummer as well, although not exactly a surprise.

The license agreement for the SDK is also fairly disappointing, in that it disallows development of apps that run interpreted code, among other things.  This may prevent Mobile Firefox from being done on the iPhone.  I for one would have liked to see someone do a port of Mobile Firefox to the iPhone, if for no other reason than to have a platform that I personally carry around with which I could show it off to people.

I also had hoped to work on porting an emulator I’ve spent several years helping to develop to the iPhone, but at first glance, I fear that the license terms may not allow emulation.  It’s a question I’ll have to ask.

At any rate, despite the minor disappointments and frustrations, the iPhone SDK is a huge, huge step in the right direction, and I’m very enthusiastic to see where things go from here.

 

MindTouch has been busily working on adding features we requested to Deki Wiki in preparation for our transition to Deki from MediaWiki, and they’ve reached the point where it’s time for us to start working on the MDC skinning.  MindTouch has someone that will be available to provide mentoring and assistance, but the job of actually creating a skin that looks like a Mozilla web site and feels right for our MDC contributors falls upon the Mozilla community.

The primary goals for the skin are:

  • Should blend in nicely with the look of the site at Mozilla.com.
  • Needs to display breadcrumbs at the top of each page (this is being moved from an extension into the skin during the Deki Wiki transition).
  • Needs to be finished by mid-April.

Now we just need someone who has the time and skills to do the work.  If you’d be interested in doing this kind of thing, let me know!  If you’d like to look at some basic information on skinning Deki Wiki, here you go: http://wiki.opengarden.org/Deki_Wiki/Templates

This is also a good time for folks to make their suggestions for things they’d like to see (or not to see) in the new skin, so that we can get those onto the list of things to try to take into account while the work is done.

© 2012 Bit Stampede Suffusion theme by Sayontan Sinha