In edit mode, the middle mouse button should always pan, even when there is an item under the cursor

• Nov 4, 2020 - 21:24
Reported version
Ergonomical (UX)
S5 - Suggestion

Currently, the "pan with middle mouse button" action seems to be implemented by treating a middle-click as a left-click. For example, if you hover over a text item and double-middle-click, the canvas will enter text edit mode.

This means that when attempting to pan the canvas using the middle mouse button, if there is an item under the mouse cursor, the item will be grabbed and repositioned instead. This can make it difficult to pan across busy scores.

I suggest that the middle mouse button should unconditionally start the "pan" operation (as though left-clicking in empty space), even when there is an item under the mouse cursor.


Do we even support middle-click as a unique operation at all? I know it's been requested that we someday support middle-click-drag for moving the canvas for the benefit of people who have three button mice that lack scroll wheels, but as far as I know this hasn't happened. In part because other people have other wishes for the behavior of the middle button, such as a shortcut for copy/paste. You might want to find the various forum discussions of this topic and comment there. if a consensus someday developers on the right thing to do, presumably it would be easy enough to implement.

My sense is, that's when middle click was implemented to just do basically the same as left click - before that it probably did nothing. But as mentioned in the notes there, there is no special behavior for middle click during note input mode. When it's come up before, there seems to be about 50/50 support for drag versus copy/paste, but mostly a lot of, "what's a middle click"? :-)

I didn't realise until now that the reason middle-click places a note, when in note input mode, is that it's imitating the left mouse button. That's a long-standing mystery I've finally figured out...

This seems like one more argument in favour of giving the middle button a consistent behaviour (whether that ends up being panning or something else). For users like me who've been trained by other programs to use the middle mouse button as the most important form of navigation, having it unexpectedly stop working in note input mode has always been a papercut.

Here's one other user who ran into the same problem:

And another user whose instinct was to always pan, rather than using the mouse wheel:

Pasting in note input mode is not currently an option, but it's been requested as well. And in case, I am not sure I'd be comfortable with different behaviors for middle-click in note input mode versus normal. So definitely worth further discussion on forum, and hopefully getting input from our design guru specifically.

Status active fixed

Fixed in branch master, commit 8c6226eddc

_Fix #312574: Always dragging with middle mouse button

Like in many apps, the middle mouse button will now always allow dragging (only dragging).
A very useful aspect of this is that you can now move the canvas using the MiddleButton, without having to leave Note Input mode._