Weekly report: June 8th 2013

Most of the tabbrowser cleanup is now done! Here is a commit merging these changes into the awesometab branch in my repo. I've been working on these changes the past two to three days - though I had some personal things to take care of which took some of my time.

To summarize the tabbrowser work so far:

• Tabbrowser-tabs are now fully transparent to the nature of their linked panels. The tab panel a tab is associated with is now stored in its linkedTabPanel property, though the linkedConversation property is still set (identical to linkedTabPanel) - it can be used to check if a tab holds a conversation, and conversation specific code is more easily understood.
• Tabbrowser now accepts non-conversation tabs and displays them without errors.
• All basic functions like moving tabs around, detaching and reattaching, opening in a new window, etc. work for these tabs.
• Tab specific context menu items are handled by getting a NodeList containing menuitems from the tab panel.
• Cleanup has been done to make tabbrowser as transparent to tab content as possible.
• Fields like mCurrentConversation, mCurrentBrowser, etc are replaced by properties which return them from mCurrentTab. This saves setting them in different places - now only mCurrentTab needs to be set.
• Some changes have been made in other files to make them aware that not every tab holds a conversation (keyboard shortcut commands for e.g.).

What's left:

• Tooltips need to be taken care of. I've looked into this and it doesn't seem to be too tricky. I currently plan to do something similar to the menuitems, where the tab panel returns its tooltip data.
• It needs to be decided whether the tabPanel binding - which now functions as an abstract class - should be kept or not. Though it doesn't do much, it can be good documentation for developers who want to add non-conversation tabs.
• As an alternative to having pre-defined methods that are expected to exist in all tab panels, DOM events could be fired and tab panels could respond to them as they wish (as suggested by flo).
• After this, the changes need to be reviewed and checked-in to fix bug 426.
• This isn't exactly a pending task, but it was proposed in IRC that awesometab's algorithm could learn from logs so that users could benefit right away.