CSSTUDIO-1986 Prevent selection of widgets in the Widget Tree using the arrow keys.

[abrahamwolk]

This pull-request prevents the selection of widgets using arrow keys in the Widget Tree. Keyboard shortcuts (e.g., Ctrl + g for grouping widgets) continue to work.

The intention of the pull-request is to prevent counter-intuitive behavior when the Widget Tree is selected when pressing the arrow keys. The issue can be reproduced as follows:

1. Open an OPI that contains the widgets "Widget 1", "Widget 2", and "Widget 3".
2. Right-click on the OPI and open the Widget Tree. Suppose that "Widget 1" is above "Widget 2", which in turn is above "Widget 3" in the list that the Widget Tree displays.
3. Left-click on "Widget 1", so that "Widget 1" is selected.
4. Left-click again on the Widget Tree, but this time on the white area below "Widget 1", "Widget 2", and "Widget 3". The consequence is that "Widget 1" is still selected in the Widget Tree, but the focus is on the Widget Tree instead of on "Widget 1".
5. Press the down-arrow key on the keyboard. Now "Widget 2" is selected, and the focus is also on "Widget 2".
6. Press the down-arrow key on the keyboard. Now "Widget 2" is moved down (moved in the y-direction) in the OPI.

That the down-arrow key changes meaning between step 5 and 6 is counter-intuitive.

With the changes in this pull-request, it is no longer possible to select widgets using the arrow keys in the Widget Tree. Instead, the foucs is placed on any selected widgets. If there are no selected widgets, the arrow keys will not have an effect when the Widget Tree is in focus.

[kasemir]

I agree that the current behavior is bad. The unpredictable or at least unexpected change from browsing through widgets in the tree view to moving them in the central editor pane is bad.

The question is what it should do. What I'd like to see is this:

If the mouse is in the widget tree, you can click on widgets to select them, or use the cursor keys to navigate the tree, that is, the selection will move with the cursor keys. That's the normal behavior of a tree view. Cursor navigation can be very useful if you want to select a specific widget within a set of overlapping widgets; a cursor up/down is faster than clicking them in the tree view, and in the editor panel they may be very hard to click because they overlap.

If the mouse is in the central editor pane, the cursor keys move the selected widgets. This is the most convenient way to interactively fine-tune the pixel position (although using the grid or snapping to nearby widgets is of course usually a better approach).

As long as the cursor position (within tree or within central editor pane) determines the behavior, that should be fine. The main issue here is that you get the "move widget" behavior while the cursor is in the tree, so you'd expect the "browse tree" behavior.

Your PR makes it predictable by killing the "browse tree" behavior altogether, which I don't think is the best solution.

[kasemir]

Having said that, I'm not sure how easy this is to accomplish. I vaguely remember that the "move widget" behavior was added via a higher level event filter that captures the keystrokes wherever the mouse is, because otherwise the "tracker" didn't dependably move. Still, I hope you can look into this since you're already in the midst of that code. If you can't figure it out, then your current PR is certainly better than the confusing "move widget" behavior while the mouse is in the tree view.

[abrahamwolk]

I will consider this.

[abrahamwolk]

@kasemir I agree that it should be possible to select widgets using the arrow keys. I have implemented an alternative fix now. However, the new version doesn't work based on the location of the mouse, but instead changes how the focus is managed.

In the new version, the focus is not automatically set on the selected widgets. Instead, the Widget Tree keeps the focus when widgets are selected. In particular, it is possible to select multiple widgets using the keyboard. If one clicks on the selected widgets (i.e., clicks on the rectangle that represents the selection), the widgets receive the focus, and key presses are directed to the selected widget(s).

[abrahamwolk]

This change I am not 100% sure about. Previously (i.e., with MouseEvent.MOUSE_MOVED), the selected items in the Display Editor were given focus whenever the mouse hovered over them. I found this behavior counter-intuitive, and with this change, they are instead given the focus by clicking on the selection using the mouse.

[kasemir]

As far as I can tell, this works very well!
At least on a Mac I can finally use the cursor keys within the tree view to change the selected widget, or use Shift + cursor keys to extend the selection. Once I click on the selection tracker in the central editor pane, I can then use the cursor keys to move the selected widgets pixel by pixel. Click in the tree view once more, and the focus is back in there.
Keyboard shortcuts to select all, group, save, undo/redo work no matter if the focus is in the tree view or central editor pane. So overall this is exactly as it should have been from the start, thanks!