use mouse down for activation of components #488
Conversation
| @@ -173,7 +173,7 @@ public synchronized Result handleKeyStroke(KeyStroke keyStroke) { | |||
| * @return index of a item that was clicked on with {@link MouseAction} | |||
| */ | |||
| protected int getIndexByMouseAction(MouseAction click) { | |||
| return click.getPosition().getRow() - getGlobalPosition().getRow(); | |||
| return Math.min(click.getPosition().getRow() - getGlobalPosition().getRow(), items.size() -1); | |||
There was a problem hiding this comment.
When a list has the screen real estate to present more items than the list actually has in it, there will be blank space at the bottom rows.
This change makes it so that clicking in that blank space selects the last item rather than throwing an exception.
|
I think, it makes sense to let certain widgets already do their action on first click, and depending on the widget it isn't even necessary to set focus on it at all, so let the "set focus" be the default (for interactive widgets), and for specifc widgets either override it for a specific action (buttons, checkboxes), or just continue having them focused (text boxes, although they could in future also set the cursor to (or nearest to) the clicked position, which is quite non-trivial to implement.) There might also be specific widgets, that may still use first click to focus them, and only every further click (i.e. a click, while they're already focused) to trigger further action. That would be widgets that would be primarly keyboard-controlled, so a user could click on it for focus and then continue with keyboard, without having that click already do anything else - TextBox would be an example for that, in my humble opinion. |
…ed and result as Result.HANDLED
|
Seeking coment: For certain components, doing the action right away on mouse click is good. Looks like space and enter were 'actioning' keys on some components, some others were only enter so I made them have space as well for consistency. I also added some clipping logic to prevent some exceptions when the mouse event locations would map to imaginary items in the lists and tables and text boxes. For the table test, I needed to have it rendered for the accurate clipping log, seems to work on my machine (mvn clean install), not sure if popping up that swing window for couple milliseconds will be a build problem. How would you like to proceed? I think that I am basically done with this issue. |
…nsistent with the rest
|
Looks like there is still a thing left to do. The mouse down is not taking into account being scrolled downward in TextBox, ActionListBox, CheckBoxList, RadioBoxList. |
|
Ok, looks like it's a wrap, got the mouse down working for list style widgets. I am wondering how to proceed to have this pull request merged. I was thinking it would be best for it to merge before proceeding onto other things so it doesn't topple. |
…eline headless issues
…ate test.jar in order to run tests from command line
|
Could you change this PR to go against release/3.1 branch instead of master? |
Yes. |
|
Thanks, that's merged now |
|
Ok, great! Thanks. |
Seeking comment.
Looks like the code was taking a direction that I'm not sure I understand the rationale, it would take two clicks for things, one for the focus and another for the activation.
Since mouse is newer terminals, not sure the case where this would be needed or desired.
This pull request collapses those, so clicking a button once causes the action. Clicking a checkbox once causes the focus and the checked state to toggle.
Clicking the RadioButton causes the focus and that button state to be true, etc.