Community
Participate
Working Groups
Need to improve tab order for ToolBar. ToolBar can contain ToolItem. If ToolItem has a control, In this case, the traverse order is parent toolbar then child controls. From the user's point of view, I think this is a kind of confusing. The traverse order should be the same as the visual order. This is one of the examples: toolItem = new ToolItem(toolBar, SWT.SEPARATOR); combo = new Combo(toolBar, SWT.None); combo.setText("Item 1"); toolItem.setControl(combo); toolItem.setWidth(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT).x); toolItem = new ToolItem(toolBar, SWT.None); toolItem.setText ("Item 2"); toolItem = new ToolItem(toolBar, SWT.SEPARATOR); combo = new Combo(toolBar, SWT.None); combo.setText("Item 3"); toolItem.setControl(combo); toolItem.setWidth(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT).x); toolItem = new ToolItem(toolBar, SWT.None); toolItem.setText ("Item 4"); In this code, the traverse order is ToolBar(item2 -> item4 by arrow key) -> Combo in item1 -> Combo in item3 by tab. But it should be item1 -> item2 -> item3 -> item4. Also, it would be great if we have a convenient API to change the traverse order like Composite.setTabList(Control[]) for Items to resolve this problem.
Adding accessibility keyword.
WE should just fix the order.
It turns out this is hard to fix. The default traversal goes down the widget tree, first traversing into the control children, then back to the parent. In the case of a tool bar, the items get traversed last. Since ToolItems are not controls, they can't be included in setTabList(). It might be possible to do something here for 3.3. How important is this bug?
Carolyn, can this be worked around by using a CoolBar instead of a ToolBar? I think we talked about this a while back. I realize this would only be a temporary solution.
Note: Milestone is currently set to 3.2.2. If that's not going to be possible, please change it.
Carolyn or Karice, any additional information on the possible work around from comment 4? This is a rather nasty accessibility issue that we would like to resolve in some fashion in the 3.2.2 timeframe.
Please try using a CoolBar and let us know if this works for you. We will not be changing traversal order of toolbars for 3.2.x.
Not sure how to work around this using CoolBar. Can you post any sample here ? Actually we are also using JFace CoolBarManager, ToolBarContributionItem, ToolBarManager, ActionContributionItem to add regular ToolItem buttons and SWT controls in ToolItems. then add the ToolBars in CoolItems in CoolBar. So to resolve this problem, can you do one of the following things ? 1. Fix in SWT ToolItem. ToolItem always creates a child control for regular button (with Button/DropDown/Check/Radio style). If each ToolItem alwas has a child control then implements Button/DropDown/Check/Radio in the child control, then tab order should work correctly. 2. Fix in JFace ActionContributionItem. ActionContributionItem always creates a child control in each ToolItem. (similar to 1.) 3. CoolBar workaround (how ?) 4. Anything else ?
If you go to http://www.eclipse.org/swt/snippets/ there is a section with some snippets that show how to create a CoolBar.
Hmmm am I missing something ? CoolItem is just a container to put a control. CoolItem has no default button (push/dropdown/check/radio) in it. So I don't think we can simply replace ToolBar with CoolBar. What does it mean "using a CoolBar instead of a ToolBar" exactly ?
Here are 2 snippets. The first one just uses a ToolBar. The tab order is confusing, as you say. The second snippet uses a CoolBar to implement basically the same thing, except that the tab order feels natural. Please try out both of these snippets, and see if you can use the CoolBar idea in your code. Please note that we cannot change the tab order of ToolBar in a point release, because it is a big change that could break other things. Snippet1: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class ToolbarTabOrderTest { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); ToolBar toolBar = new ToolBar(shell, SWT.FLAT); new ToolItem(toolBar, SWT.None).setText ("Item 1"); new ToolItem(toolBar, SWT.None).setText ("Item 2"); new ToolItem(toolBar, SWT.None).setText ("Item 3"); ToolItem toolItem = new ToolItem(toolBar, SWT.SEPARATOR); Combo combo = new Combo(toolBar, SWT.None); combo.setText("Item 4"); toolItem.setControl(combo); toolItem.setWidth(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT).x); new ToolItem(toolBar, SWT.None).setText ("Item 5"); toolItem = new ToolItem(toolBar, SWT.SEPARATOR); combo = new Combo(toolBar, SWT.None); combo.setText("Item 6"); toolItem.setControl(combo); toolItem.setWidth(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT).x); new ToolItem(toolBar, SWT.None).setText ("Item 7"); new ToolItem(toolBar, SWT.None).setText ("Item 8"); new ToolItem(toolBar, SWT.None).setText ("Item 9"); shell.pack (); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } Snippet2: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.layout.*; public class ToolbarTabOrderTestWithCoolbar { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); CoolBar coolBar = new CoolBar(shell, SWT.BORDER | SWT.FLAT); ToolBar toolBar = new ToolBar(coolBar, SWT.FLAT); new ToolItem(toolBar, SWT.None).setText ("Item 1"); new ToolItem(toolBar, SWT.None).setText ("Item 2"); new ToolItem(toolBar, SWT.None).setText ("Item 3"); CoolItem coolItem = new CoolItem(coolBar, SWT.NONE); coolItem.setControl(toolBar); Point size = toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT); coolItem.setSize(coolItem.computeSize (size.x, size.y)); coolItem.setMinimumSize(toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT, true)); Combo combo = new Combo(coolBar, SWT.NONE); combo.setText("Item 4"); coolItem = new CoolItem(coolBar, SWT.NONE); coolItem.setControl(combo); size = combo.computeSize(SWT.DEFAULT, SWT.DEFAULT); coolItem.setSize(coolItem.computeSize (size.x, size.y)); coolItem.setMinimumSize(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT, true)); toolBar = new ToolBar(coolBar, SWT.FLAT); new ToolItem(toolBar, SWT.None).setText ("Item 5"); coolItem = new CoolItem(coolBar, SWT.NONE); coolItem.setControl(toolBar); size = toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT); coolItem.setSize(coolItem.computeSize (size.x, size.y)); coolItem.setMinimumSize(toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT, true)); combo = new Combo(coolBar, SWT.NONE); combo.setText("Item 6"); coolItem = new CoolItem(coolBar, SWT.NONE); coolItem.setControl(combo); size = combo.computeSize(SWT.DEFAULT, SWT.DEFAULT); coolItem.setSize(coolItem.computeSize (size.x, size.y)); coolItem.setMinimumSize(combo.computeSize(SWT.DEFAULT, SWT.DEFAULT, true)); toolBar = new ToolBar(coolBar, SWT.FLAT); new ToolItem(toolBar, SWT.None).setText ("Item 7"); new ToolItem(toolBar, SWT.None).setText ("Item 8"); new ToolItem(toolBar, SWT.None).setText ("Item 9"); coolItem = new CoolItem(coolBar, SWT.NONE); coolItem.setControl(toolBar); size = toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT); coolItem.setSize(coolItem.computeSize (size.x, size.y)); coolItem.setMinimumSize(toolBar.computeSize(SWT.DEFAULT, SWT.DEFAULT, true)); shell.pack (); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } Hope this helps! Carolyn
Sorry for my late response... If we are creating a SWT standard application, I think the above workaround would be acceptable. from Eclipse RCP app point of view, we would like Eclipse to resolve this issue. We use org.eclipse.ui.actionSets for the regular toolbar buttons and org.eclipse.ui.menus for the regular toolbar buttons and for the custom control in toolbar. in that case, I don't think we can apply the above workaround... We know the root problem is ToolItem is not a control, it is a part of ToolBar control, that's why all the ToolItems are traversed first, then control in ToolItem are traversed next. So, if it is difficult to have a fix in SWT ToolBar, can Eclipse have a fix in the upper layer, in jface or in Eclipse workbench ? For example, ActionContributionItem.fill(ToolBar,int) in jface creates a standard SWT ToolItem button. but instead, can Eclipse add a button control in the new ToolItem in ActionContributionItem.fill(ToolBar,int) ?
Adding Kim and Paul for added insight.
any plans for this in 3.5?
CC'ing SSQ to see if he can think of a way to make this work on the SWT side (SSQ see comments 0 - 3 for discussion, and see comment 11, snippet 1). Paul & Kim, do you have any comments on the suggestion in comment 12, which may help work around this problem by avoiding it in JFace?
Paul, we should probably sit down and talk about this when you get in tomorrow, but at first blush it seems like a really bad idea for Jface to start using button controls instead of real tool items. We would be opening a whole new can of worms for what seems to be (from my perspective at least) not that serious an issue.
We won't use button controls instead of tool items.
(In reply to comment #15) > Paul & Kim, do you have any comments on the suggestion in comment 12, which may > help work around this problem by avoiding it in JFace? We won't be able to work around this in JFace at this time, at least not using CoolBars (we can look at some other suggestions as well). PW
Notes Domino: Hiro indicates that Eclipse should implement this for the standard ToolBar, then we will apply the same pattern to SToolBar. This is failure of checkpoint 1.1 and must be fixed in 8.5 This bug must be put on the critical bug list and a target fix date established. Escalated via email from Pete Miller/Westford/IBM to Pat Huff/Raleigh/IBM 07/11/2008 09:28 AM
Note that the tool bar is still accessible using a combination of tab and arrow keys.
Not for 3.4.1. We have some idea how to change the traversal order, but we don't have the code yet.
Is this being considered for 3.5?
Steve & Car: will this bug be fixed for 3.5 ?
We have released the fix in HEAD for win32. We'll be fixing GTK as well. Please try your application with SWT from head and see it that is the behaviour you expect.
GTK fixed too. Fixed in HEAD > 20090427
