Now that the Australis curvy tabs are in the polishing state, it’s time I turn my attention to the second part of Australis – the new customization experience.

Customizing Firefox’s UI has always been a little bit funky – you right click on a piece of chrome and choose Customize (or if you knew about it, go to View > Toolbars > Customize), and then a window pops up that lets you drag items to and from it. When this window is open, you are in the customizing state, so you can move buttons all over the place.

The new customization experience that the UX team has designed is quite a bit smoother. I can describe it, or, even better, I can show it to you.

Instructions:

1. Go here to see bwinton’s awesome prototype
2. Hide the main navigation bar for a more immersive experience (View > Toolbars > Navigation Toolbar)
3. Click on the menu button in the right corner, and choose “Customize”
4. WHOA
5. Now drag some items from the customize palette onto the toolbar, or into your menu.

Pretty snazzy, and it does away with that old customize window, which is excellent.

Blair McBride has been working on this feature for a little while, but due to health issues, the project has been handed to Jared Wein and myself. And I suppose when Blair is back at 100%, it’ll be all three of us hacking on it. Or something like that.

So, everything I just wrote above? That was for you, to let you know what I’m looking at during my day. Everything below the “Notes to self…” header are my notes as I browse through the customization code as it is. Just going to jot down notes and observations, etc. You might find this interesting, since it will show you my thought process as I go.

Or you might think it’s just a confused and bewildered miasma of incoherent rambling and nonsense. Well, we’ll see how it goes.

Notes to self…

Glossary:

• Panel – the thing that opens when I click on the three-line menu toolbar button (a.k.a “the hamburger” – sorry shorlander) in the nav-bar
• Widget – what used to be considered “toolbarbuttons”. It’s a thing that can be in the panel, in the customize palette, or in a customizable toolbar
• Customize palette – what used to be a new window is now an in-content selection of widgets you can chuck into the panel or customizable toolbars

So I know we’ve got ourselves a panel, and there’s a whole bunch of customization logic. There was also this API thing that Blair was working on so that add-ons could specify widgets through their chrome.manifests. And there also appears to be some work to be somewhat backwards compatible with the ol’ overlay approach to adding widgets.

The big mama seems to be browser/modules/CustomizableUI.jsm. This module seems to be responsible for a ton of stuff, including (but not limited to):

• Panel open / closed state
• Panel populating
• Menu button pressed / unpressed state
• Persisting and restoring customization settings
• Catching “I dun get it” notifications from the chrome.manifest parser to see if it’s a widget that’s in there
  • Reading JARs or uncompressed files from the manifest to create widgets
• Being the central hub of knowledge about where widgets are, and firing notifications when widgets are added, removed, moved or destroyed.
• Knowing about which widgets are not being used, which lets us populate the palette tab when we enter customization mode
• Allowing us to enter and exit the customization mode
  • That appears to be leftover cruft.  browser/modules/CustomizeMode.jsm seems to manage that now. I’ll remove the old cruft.

There’s this notion of “customizable areas” too. It looks like we’re constraining the customizable areas for now, and so we have an area between the URL bar and the menu button that we can drag and drop items to. The panel is also an area. When we enter customization mode…

Ok, this is pretty neat. When we enter customization mode, we suck out the panel, and drop it into a panel holder in the customization tab. That way, we can see the panel and add to it while customizing. Ok, I get that.

There was originally the idea of de-coupling the panel from the customization code. That might actually still be possible. I had tried that earlier, but was discouraged when I found out that the CustomizationUI.jsm was responsible for populating the contents of that menu panel too, meaning that the panel code itself was rather useless without the customization stuff. Maybe this needs more thought – because it would be nice to de-couple them a bit more.

Maybe I should work harder at de-coupling the menu stuff from the customization stuff – especially now that it looks like the panel is a little more complicated than just a widget drop point. Now widgets can have “subviews”, like the bookmarks widget. This means that stuff either slides out or moves over in the panel when clicking on a particular widget. Having all of that jammed up in CustomizableUI.jsm isn’t ideal – maybe I can split it out to help us separate our concerns a bit more.

Ok, I think I’ve convinced myself. I’m going to spend the rest of the afternoon trying to devise a strategy to de-couple these two.