The aim of M1, as stated in the summary for the bug that I am working on was
When a tab in the overflow menu is active, highlight the overflow menu (or scroll the tab bar).I really do not like the overflow menus in Safari, or Camino. They do not feel like a nice and clean way to deal with the problem. It turns out that there isn't actually a nice and clean way to deal with the problem and that I will probably have to allow people to use overflow menus as a control-click option. Or that the whole ticker-style implementation might need to be dropped and I'll have to have double overflow menus which simply bring the active tab and the tabs around it into the tab bar. (In retrospect, that would have been a thousand times easier to implement, but it is not nearly as pretty). However, I stand by my decision to implement it as a ticker bar because the point of M2 is to allow users to drag tabs to reposition them and the mere thought of having users drag things out of menus makes my head hurt.
It turns out that the people developing Firefox 2 are also working on a ticker-bar for their tabs. Is this a case of great minds think alike or that fools differ?
Jasper Hauser proposed that things should look like this. Things do kind of look like that, I have removed the double headed arrows and replaced them with some shoddily ripped direction arrows as you are used to seeing in all OS X scrollbars. Hopefully when Jasper is less busy he can provide us with some really nice icons.
The following features / benefits will be available to users:
- When a user has more tabs than what can currently fit into the tab bar, two arrows will appear at their side of the bar that indicate their state (disabled if a user cannot scroll in that direction)
- Clicking on either of these arrows allows a user to scroll along their tabs in that direction, it this is possible.
- If a user expands the window and there are more tabs to right then these tabs shall be shown first; if the user has expanded the window and there are no more tabs to the right then start showing more tabs to the left.
- If a user shrinks the window and then the active tab will always stay visible in the tab bar - at the right most of the tab bar is the shrinking causes it to not be in the tab bar.
- If a user has scrolled away from the active tab to the left and use full keyboard access to change the currently active tab then the tab bar will scroll back to show the active tab left-most. If they are scrolled away to the right then and FKA commands issued to Camino will cause the active tab to be the right-most.
- Newly created tabs that are not set to load in the background will always grab the attention and shift the tab bar so that the right-most tab is the newly created tab. *
Simon Fraser has continuously voiced his opposition to a scrolling tab bar because he believes it to be bad for positional memory. Although he appears to have softened up ever so slightly if I animate the scrolling. Having the tabs visually move is not a requirement for WIP4, and is more of a polishing exercise that will be part of WIP5. I think that Pink might be happy enough to SR+ WIP4 after it has been R+ (which might take a few iterations)
The are only 3 bugs - in terms of what I have tried to achieve:
- Click-and-hold does not continue to scroll along the tabs in the appropriate direction.
- If the active tab is to the left then there is no divider drawn between the left scroll button and the first tab (I know what it causing this, but am flummoxed as to how to fix it)
- I forgot the third one.
Hopefully some real user testing after being SR+d will point out the subtle problems and performance issues.
* This makes me wonder whether or not opening links in a new tab should create that tab to the immediate right of the currently active tab or not. But that is a conversation for another day!