Community
Participate
Working Groups
Accessibility: Cannot access the CheckboxCell/TextCell/ComboBox Cell using the keyboard. Using the mouse, you can access each of the cells and change the values of the cells. The cells are made up of checkbox, text, and combo box. However, using a keyboard, there's no way to change to value.
SWT does not support tabbing between cells in a Table or TableTree because the OS widgets do not support it. Applications like spreadsheets which have this functionality typically do so by writing their own widgets. SWT is intended to be a thin layer on the OS so adding support for this at the SWT level goes against its design philosophy. Having said this, there is a class called TableCursor in org.eclipse.swt.custom which does support this kind of behaviour, on top of a Table widget. It only uses public SWT API, and does not introduce any new kinds of widgets. It simply manages repositioning a TableEditor by hooking key events. It could be copied and adapted to an application's needs, or adapted to work on a TableTree fairly easily. However, it still has a fairly non-standard look and feel. This is due to its placing controls on top of the Table, so the Table is not actually the active widget. Its selection is therefore grayed instead of blue. We considered using this for the Tasks view, but decided against it due to this problem, and went with a separate properties dialog to address accessibility instead. In my opinion, going this route also improved general usability for entering/modifying tasks. In other places, like the Properties view, the keyboard handling is defined by the view itself. Since there is only one editable cell per row, this is fairly straightforward and does not require tabbing between cells. JFace defines the TableViewer, TableTreeViewer and CellEditor abstractions on top of the SWT Table, TableTree and TableEditor widgets. However, it does not provide keyboard support either because it was felt that the rules for which keys should do what are application-specific and do not belong in JFace either. This belief was strengthened by experimenting with TableCursor for the Tasks view since TableCursor makes certain assumptions which don't necessarily apply in all situations. We decided not to adopt its use in the JFace viewers for this reason. There are no plans to change this for 2.0. It is the application's responsibility to handle keyboard navigation of tables. Or, it can provide an alternative to table manipulation such as a properties dialog, as we did in the Tasks view. Note that it should be possible for an application to use TableCursor (or something like it) and TableViewer at the same time. The application can activate a cell editor in response to a TableCursor selection callback using TableViewer.editElement(...).
Reopened for investigation
Closing PR as the TableCursor takes care of this.
Marking closed
