Bug 331883

Comment 1 Scott Kovatch 2010-12-06 11:50:48 EST

To navigate within the items of a ToolBar use the arrow keys, not tab. Tab and shift-tab take you to the next and previous tab group, if any.

Toolbars in Cocoa are emulated, so there's no Cocoa equivalent we can use for guidance here. It's similar in behavior to other platforms, though.

Comment 2 Marcel 2010-12-07 02:26:18 EST

Did you try to reproduce?
For me, using the cursors does not work.
Testing a bit more showed that:
- assume you have 3 toolitems
- hit tab once -> you get to the first
- hit tab 3*2 times, the focus is again on the first toolitem
-> however the other toolitems never get the focus
-> cursors do not work
-> if you have another control (e.g. text) after the toolbar, it is not possible to navigate there using the tab key

To me this is broken. Unsure whether it is fixed in >3.6 (I have not direct access to a Mac, it is cumbersome for me to test this).

Comment 3 Scott Kovatch 2010-12-07 12:24:02 EST

(In reply to comment #2)
> Did you try to reproduce?
> For me, using the cursors does not work.
> Testing a bit more showed that:
> - assume you have 3 toolitems
> - hit tab once -> you get to the first
> - hit tab 3*2 times, the focus is again on the first toolitem
> -> however the other toolitems never get the focus
> -> cursors do not work
> -> if you have another control (e.g. text) after the toolbar, it is not
> possible to navigate there using the tab key
> 
> To me this is broken. Unsure whether it is fixed in >3.6 (I have not direct
> access to a Mac, it is cumbersome for me to test this).

Yes, it was fixed as part of bug 276566. By design, tabbing only works from one ToolBar to the next, and then if desired, the arrow keys can be used to navigate from item to item. Note that cursor navigation only works if you have full keyboard access turned on (hit ctrl-F7).

This code works for me in HEAD. Please run it and let  me know what isn't working for you.

===========================
import org.eclipse.swt.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.widgets.*;

public class Snippet18 {

public static void main (String [] args) {
	Shell shell = new Shell ();
	shell.setLayout(new RowLayout());
	ToolBar bar = new ToolBar (shell, SWT.BORDER);
	for (int i=0; i<4; i++) {
		ToolItem item = new ToolItem (bar, SWT.PUSH);
		item.setText ("Item " + i);
	}
	bar.pack ();
	ToolBar bar2 = new ToolBar (shell, SWT.BORDER);
	for (int i=4; i<8; i++) {
		ToolItem item = new ToolItem (bar2, SWT.PUSH);
		item.setText ("Item " + i);
	}
	bar2.pack ();
	Text text = new Text(shell, SWT.SINGLE);
	shell.pack();
	shell.open ();
	Display display = shell.getDisplay ();
	while (!shell.isDisposed()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
	display.dispose ();
} 
}

Comment 4 Marcel 2010-12-08 03:18:06 EST

Hmm, using the last nightly (N20101204) and it works a bit better. However the amount of 'tab'-key-presses to get out of the toolbar again (without full-keyboard-access) is too high IMO (it needs > 5 keypresses). I think this is the behavior described in bug 275957.
Having full-keyboard-access turned on and using your snippet below, I can navigate in the first toolbar, but the second one never gets the focus. As bug 276566 should already be fixed for 3.6. (and bug 275957 is a dupe of that and should thus be fixed already, too), I'm a bit confused. As far as I could see, it did not work at all in 3.6. and is in the state that bug 275957 describes up to now...

Also your comment about how it is designed with cursor and tab does not cover with my testings as the cursor never works for me.

It would be nice if you could have a look again and verify it works as designed and intended.

Comment 5 Scott Kovatch 2011-01-04 12:53:01 EST

(In reply to comment #4)

> It would be nice if you could have a look again and verify it works as designed
> and intended.

My testing was with 3.7M4 and the HEAD revision of SWT. That works as expected. I just tried again with 3.6.1, and I can see the problems you describe with the excessive tabbing. With the latest 3.6 maintenance branch it behaves the same as HEAD, so that leads me to believe this will show up in 3.6.2.