Community
Participate
Working Groups
The new "go left" and "go right" tools that were added to the CTabFolder recently need several accessibility and usability improvements: 1) they need to be image tool buttons instead of the strings "<" and ">". This would make them look more polished, and it would keep screen readers from saying "less" and "greater" when the tools get focus. 2) they need to have tooltips. What are they called? What do they do? I have just been calling them "the less and greater guys". You probably want some nice tooltip strings. In addition to helping sighted people determine their function, this would allow screen readers to speak their function. (This assumes that the toolbar is being managed by ToolbarManager, because that class contains a hack for using tool item tooltip strings for the accessible names. If they are not managed by ToolbarManager, and if it is decided that ToolbarManager should not manage these toolbars, then they need). 3) they need to be disabled when pressing them would do nothing. For example: a) when there are no tabs to the left, the < should be disabled b) when there are no tabs to the right, the > should be disabled c) when all tabs are visible, both < and > should be disabled 4) for some reason, they are reversed in the tab order, i.e. if you are in an editor and type ctrl+shift+tab to traverse backwards to these buttons, you will traverse to < first and then > ...but when traversing backwards you really should go to > first and then <.
Point 2) in comment 0 is incomplete. I meant to say that any toolbars not currently managed by ToolbarManager need to have special accessibility code added. For point 3) I now think it would be better if the buttons went away when they are not needed. (i.e. don't just disable them, get them out of there). They look a bit silly sitting there, useless. Make them invisible and get them right out of the layout so that you can claim a bit more screen real estate. a) when there are no tabs to the left, the < should not be there b) when there are no tabs to the right, the > should not be there c) when there are no tabs, both < and > should not be there I think this whole concept of scrolling within the tabs would play better if it was rearchitected so that the < and > were implemented completely within CTabFolder, and not part of some framework that CTabFolder supports. See also bug 369978 which says that keyboard traversal of the tabs is also broken in e4.
See also bug 370438.
+1 for the additional insight and discussion on bug 370438.
I think the only way to do this properly is inside CTabFolder (sorry Bog). Then CTabFolder would have API to turn the <> feature on/off [default off], something like: setTabScrollingVisible(boolean tabScrolling) Then remove the addTabControl(Control control, int flags) API that was just added to support this (semi-externally) from CTabFolder. I don't think that API makes sense for this feature. Tab scrolling is something that is just "too internal" to CTabFolder - too "entangled" <g>. Of course, the API changes would need to be done before M6... (March 16) Does anyone agree? I'm afraid a decision either way needs to be made quickly, which is why I cc'd so many folks on this bug.
(In reply to comment #4) > I think the only way to do this properly is inside CTabFolder (sorry Bog). > Then CTabFolder would have API to turn the <> feature on/off [default off], > something like: setTabScrollingVisible(boolean tabScrolling) > Then remove the addTabControl(Control control, int flags) API that was just > added to support this (semi-externally) from CTabFolder. Would the behaviour be mutually exclusive with setMRUVisible(boolean)?
> Would the behaviour be mutually exclusive with setMRUVisible(boolean)? Are you hoping that my answer is 'yes', or are you hoping for 'no'? ;) Personally, I find the MRU behavior (if it's what I think it is) a bit confusing. Tabs seem to "disappear randomly". I can get myself in a situation where I maximize an editor and restore it, and its tab is completely gone (doesn't happen every time, but often enough). The editor body (the StyledText) is still there, but the tab has "magically disappeared". It can be somewhat disorienting <g>.
(In reply to comment #6) > > Would the behaviour be mutually exclusive with setMRUVisible(boolean)? > > Are you hoping that my answer is 'yes', or are you hoping for 'no'? ;) API-wise I think it makes sense for them to be mutually exclusive. As to what I prefer, I don't like MRU but that's just me.
> API-wise I think it makes sense for them to be mutually exclusive. Yes, I agree. If people want MRU behavior in the IDE, they can get it in a nice logical way using the Back and Next arrows in the toolbar, or Ctrl+F6 and Ctrl+Shift+F6 from the keyboard.
> I don't like MRU but that's just me. It's not just you. :) Although to be honest, it was apparently added in 2004 in bug 72217 and I never noticed it until 4.x, when it suddenly became annoying. Perhaps there's just a bug in the 4.x version somewhere?
*** Bug 370438 has been marked as a duplicate of this bug. ***
I believe we need to commit (and soon) to a solution to the tab scrolling arrows. The solution potentially involves API changes in CTabFolder and the current styling is, frankly, too ugly to ship. I agree with Carolyn's assessment that the scroll arrow support needs to be implemented in CTabFolder. If we can't get the drop down list chevron statically positioned on the right hand side of the scroll arrows, then no amount of polish will make them palatable. In addition to being confusing, there are all kinds of redraw issues with the chevron as it moves left and right as tabs are opened. That being said, I would also like to make an argument for simply removing the scroll arrows. In previous recent work we have: 1) Added the ability to turn on MRU behaviour 2) Changed the chevron drop down list to be sorted alphabetically Those two fixes, I believe, add (back) considerable value, but is there really anybody clamoring for browser style tab scrolling? In a perfect world with unlimited resources, sure they would be nice to have. But I don't believe they are necessary. Especially in light of the list of work that needs to be done to make them viable. This list is a summary of what others have already noted on this bug and bug 370438 as well as a couple of new ones from me: 1) Image based arrows. 2) Chevron to right of right scroll arrow 3) Arrow visible only when tabs exist that need scrolling 4) Arrows provide accessibility support 5) Arrows need correct keyboard tab focus ordering 6) API to turn arrows off 7) Scrolled tabs should not reset position on window resize. (yes that currently happens) 8) Change chevron graphic to some kind of down arrow (like Firefox)
I agree 100% with Dean's argument to simply removing the scroll arrows for now, and deferring this feature to another time. It doesn't make sense to bend over backwards to do this properly this close to API freeze. And if the scroll arrows are removed, then the CTabFolder.addTabControl(Control control, int flags) API should also be removed, because without the scroll arrow feature, this API is useless and misleading.
(In reply to comment #12) > I agree 100% with Dean's argument to simply removing the scroll arrows for now, > and deferring this feature to another time. It doesn't make sense to bend over > backwards to do this properly this close to API freeze. > And if the scroll arrows are removed, then the CTabFolder.addTabControl(Control > control, int flags) API should also be removed, because without the scroll > arrow feature, this API is useless and misleading. +1.
Comment 11 and comment 12 makes sense to me, +1.
See also bug 369531 .
*** Bug 369531 has been marked as a duplicate of this bug. ***
As discussed on Tuesday will be implementing comment #11 on Thursday unless there is a negative outcry.
Removed the arrows http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=13442be1e0733d1daffcaf896596e87a30e61570 Closing this defect as I believe anybody that really wants/needs scroll arrows should open a feature request for scroll arrows in the tabs.
Verified in I20120313-0610. The tab scrolling is gone and the MRU is working for me.
