Selection tool has unexpected behaviour

[mukoki]

Observed behaviour of selection tool

left click a feature : replace selection by newly selected feature(s) : OK Ctrl+Maj + left click : add to / remove from selection during the time keys are pressed : OK but Maj+Ctrl + left click : add to / remove from selection "permanently" After the combination Maj+Ctrl (Maj pressed "before" Ctrl) the selection mode is changed permanently It means that after this combination, you entre the additive mode without pressing any key To return to normal mode (replace selection mode), the only way is to pressed Ctrl key alone.

=> we can get what we want but with unusual and unintuitive sequence of key combination

Proposition :

1 - Maj+Ctrl should not change selection mode Maj+Ctrl + left click should act exactly as Ctrl+Maj + left click (order of key pressed should not change the behaviour) : both should allow additive mode during the time Ctrl and Maj keys are pressed and return to the replace mode after Ctrl and Maj keys are released

2- To be able to change selection mode permanently, we could use the Caps Lock key

[jratike80]

I believe it is not Maj+Ctrl (Maj means the Shift key, right?) that is changing the selection mode. It is the Shift key alone, and it is documentet in the Shortcut Info page.

[mukoki]

You're right Jukka, as usual,

Do you mean the behaviour is OK for you ? I still think it is unusual for at least two reasons

• using 2 different keys : Shift to get the additive mode and Ctrl to get the replace selection mode seems a bit complicated
• if you use Ctrl+Maj depending on the first touch you hit, the change will affect the behaviour permanently or just the time keys are pressed

[jratike80]

Do you mean the behaviour is OK for you ?

For me, yes. Obviously my left hand is so accustomated to press the Ctrl first that I have never faced that issue. For others it might be surprising. Actually I have not been thinking that it is possible to turn on the additive mode permanently.

[mukoki]

OK, selection is usable if you know exactly what each key do, but I'm pretty sure that changing permanently the selection tool behaviour after a shift or a ctrl key hit is a side-effect of something which was not wanted at the first place. I tried to modify it but I could not make it work as I think it should, that is :

- no modifier pressed :         replacement mode, always
- ctrl+shift modifier pressed : addition mode, always

The confusion is probably related to the combination of several KeyListeners : one on QuasiModeTool changing temporarily SelectTool to PanTool when Shift is pressed and another in AbstractCursorTool changing the selection tool behaviour if Shift is Pressed - along with ctrl) : I first thought that KeyListener order was the origin of the confusion, but after changing MultiRecursiveKeyListener code so that I can change the KeyListener order, the problem is still there. @Ede, I can't imagine a good solution to simplify the code. Do you think it is possible to have a single KeyListener to dispatch events where it is needed or have you an idea of what happens in this particular case.

[edeso]

hey Mike @mukoki ,

let me have a look and come back to you. tried to contact your orange mail wrt. to a new release inbetween. did you get those? any objections?

sunny regards.. ede

[mukoki]

I now have a better idea about what the problem is with listeners and some thoughts about how to improve. Problem When shift is pressed with select tool active, quasi-mode switch immediately to pan tool and the next key released is captured by pan tool not select tool. AbstractCursorTool listeners can be activated/deactivate at any time which make it very difficult to know the state of keys. Ideas Maybe a safer approach could be to have a single permanent KeyListener with two functions :

• activating the right tool after each event (like QuasiModeTool), but maybe this part is already OK
• saving the state of modifier keys so that at any time, a tool which need to know if a key is pressed or not can get this information without relying on its own listener.