> other tests, I've just seen in all focusable Text components TextInput, > TextArea and TextPane) that the Select All (<CTRL>A) is handled in the right > way :-) > > I was thinking to propose the same behavior also for Lists, Tables, Trees > (when enabled and with multiple selection and not in edit) but I've seen > that many applications handle this in different ways, for example Outlook vs > Excel, so probably this really makes sense (as a default) only for editable > Text components, what do you think ?
Agreed that this is application-specific. > In TextInput navigation between words (<CTRL> left/right arrow) is not > working That's because it hasn't been implemented in TextInput. :-) Feel free to submit a JIRA ticket for this. > selection should be from the starting position (first triggered keys > combination) to the current cursor position, and any time the same > combination is triggered the cursor should move and so the selection > changes, and what is not selected should become selected, and vice versa. I won't say that this is exactly "by design", but it is intentional. The current selection behavior was easiest to implement (note that it is also the same behavior as in previous releases). It's not ideal, but I think it is good enough for now. We can revisit it in a future update.
