CTRL+mouse down on a movable element results in loosing focus
Reported version
3.2
Priority
P2 - Medium
Type
Functional
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
If an element has a focus, then:
1) mouse down + SHIFT allows to move it vertically
2) SHIFT + mouse down allows to move it vertically
3) mouse down + CTRL allows to move it horizontally
However, on
4) CTRL + mouse down, the element just looses focus and no movement is possible.
If an element didn't have a focus before mouse down then all combinations work fine, though.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.2.3.7635, revision: d2d863f
Comments
ctrl+mouse down adds/removes an element from a list selection so the results are not surprising. Most programs I've seen restrict movement to either horizontal or vertical when the shift key is pressed and bases the direction on the direction the mouse is moved.
I think that in most design software selection happens on mouse click. Just a mouse down starts dragging operation. In this case functionality is not symmetric and therefore unexpected/annoying. As for selecting multiple items, I think it's mouse click which usually triggers (un)selection, which by definition is a mouse-down and mouse-up in the same location, separated by a small time interval.
You can test it even in the file explorer - select item, hold control, mouse down on the same or another item, disconnect mouse. After reconnecting mouse you will be in a dragging mode.
Testing in file explorer. I selected a few items using ctrl+click. I then ctrl+clicked another item. While the mouse button was still down, I moved the mouse and all items selected were copied. The copy was not completed until I released the mouse, that is, the duplicate files did not appear until mouse release. This is a nicety that reduces the chances of an accidental copy. Also, while ctrl+clicking items, the highlighting occurred when the mouse was moved over the item, but got darker when the mouse was released. This I think is an inconsistency in Windows. The highlighting should show the selection, but it doesn't.
This tells me that in windows, it is expected that ctrl+mouse down is what selects/deselects an item in a list as I indicated. I'm not saying that something doesn't need to be rethought, but don't change what users expect from the norm.
Man, this issue is so obvious to me... It's annoying and whatever's your point, deselecting an item while dragging it instead of moving the item has absolutely no sense. I can't think of a user scenario when somebody does CTRL + drag and doesn't want to move an item.
If I understand correctly, the real-world problem is that if you accidentally select element before attempting to Ctrl+drag it, the toggle selection action gets initiated when you are really trying to drag. The solution of course is not to not get in the habot of selecting before dragging, but sure, that will happen accidentally from time to time. So a second drag operation may indeed occasionally be required. Another way around it is to get in the habit of not pressing Ctrl while initiating the drag, but rather only adding Ctrl after starting the drag. Eg, click the item without Ctrl, but then add Ctrl before you start the drag. Back in the day this used to not work at all, so when this workaround was implemented I got in that habit and over the yeara forgot it was ever an issue.
That said, indeed, we could some day look at differentiating the events further. Making it work cross-platform is always a challenge because different OS's send the events differenty.