"no drop" mouse pointer badly positioned

• Nov 24, 2018 - 20:40
Reported version
P0 - Critical
S3 - Major

I'm on Windows 10, using an up-to-date master as of earlier today, Nov 24.
In any score, drag an ornament or articulation or whatever you like onto a note head. The red "no drop" cursor is positioned differently than the "it's ok to drop here" cursor, in terms of the actual point or tip of the arrow, so to speak. I'm am unable to do screen captures because it's in the middle of the drag 'n' drop operation. I would have to post a video! I can do that if necessary, but I'm hoping you'll see what I mean without it.
The problem is illustrated best this way:
You can position the "no drop" cursor directly on top of a note, it does not change, you must position the red circle underneath and to the right of the note head, and then it changes to the arrow with the plus sign. I believe there is a way to set the "active"point in the mouse pointer icon. It seems to me that the no drop pointer/cursor needs adjusting that way.
I'm marking this issue as "minor", not "major", but it's really more like "medium". Check it out and see how goofy it gets if you miss the note initially.


Status active needs info
Priority P1 - High

I can drop articulation onto a notehead without visible issues. Would you mind recording the gif to show the issue?

Here it is as an mp4, not a gif. I too can drop the items without a problem, but the position of the mouse pointer changes and makes it clumsy.
Wow, I just recorded this mp4 using the Windows XBox game recorder (built-in to Windows 10), and the video capture looks different from my screen when I recorded it. It looks worse! Maybe it's illustrating the error itself somehow. Very strange.

Try testing it this way: Can you put the red circle cursor on top of the note head? I can. I have to move the cursor down and to the right to get it to switch to the arrow with a plus sign. That is the problem. This might be a problem that is exclusive to Windows 10.

The mp4 is too big to upload, so here is a link on my dropbox:

If you don't know already, to launch the XBox screen recorder press the Windows key on the keyboard + the letter G. Then say "Yes" the application you are recording is a game. Video record controls pop up after that. I have no third party video capture app on my PC.

Now that I think about it, I don't recommend using the XBox game recorder. I use it because I started using it and liked its HD resolution and general accuracy. But it also launches a service that can hog CPU every time you open an app you have designated as a game. I have reset options and I still have to manually shut down the service at times. A real pain...

Status needs info active

For me, the position of the drag & drop cursor seems way off a lot, and I think I finally figured out why - it has to do with where within the palette cell I click when initiating the action. If I click toward top left, things are fine. If I click towards bottom right, then the element being dragged is a long ways from the mouse pointer. And I too often have difficulty getting the drop zone right, not sure if that's another symptom of the same problem or not.

Not sure if it's that way for anyone else, but it is for me, so I could investigate this myself. Luckily, we have double-click; we could completely disable drag & drop and not be much worse off for it (except for the new staff type change element, which can only be added that way)

For me the mouse pointer is offset in the same position every time, regardless of where I start the drag. On the other hand, the icon for the element I am dragging is offset from the cursor in the way that you describe. If I drag starting in the upper left corner, the icon is on top of the mouse pointer. If I start the drag in the lower right, the icon is quite far away from the mouse pointer.
During the drag operation there is a sort of dual mouse pointer, the mouse pointer itself, and the icon of the element you are dragging, such as a fermata.
The "drop here" mouse pointer/cursor is correctly positioned in all of this, it's the red circle with a slash through it that is badly positioned.
Marc raises an additional issue of the relative positioning of the dragged element icon, at least that's how it appears on my PC.

I don't know about other operating systems, but in Windows each mouse cursor has a hot spot, a single pixel that is the active point in the icon. It seems to me that this hot spot is incorrectly set for this no-drop cursor. It should be set to the center of the circle, and it appears to be set in the upper left corner.

Both me an Marc use Windows. I believe Marc is onto something. See this video that makes the difference quite clear.

Notice the different location of the staff text in my example compared to the cursor. The round cursor makes it difficult to find the sweet spot for dropping elements also.

drop text.gif

Mike, your video demonstrates the behavior more accurately described in my follow-up post, not Marc's original. It is the distance between the staff text icon and the mouse pointer that changes based on where you start the drag within the palette. From a UI perspective, that's actually a separate issue from the bogus hot spot, which your video also illustrates. The solution might be one and the same thing, though I doubt that, because the "drop here" cursor is correctly positioned, but still varies in distance from the dragged element's icon.

In reply to by sideways

Marc mentioned that the position of the dragged element is affected by where in the cell you click. My setup help to illustrate this point. I honestly think there is more problem with the cursor shape than with the destination hot spot. Cursors usually have a point on them so you know where they are pointing (no pun intended). The current cursor is a circle and it is non-intuitive where the relationship between the cursor and destination should be. The different locations of the dragged element only magnify this issue.

Your video illustrates both issues. I'm not trying to say which problem is bigger, just that they are two separate issues, and that this issue number was created about the hot spot. I don't know if a separate issue should be created for the second issue. I'll leave that up to you all.

The red circle with a slash through it is a standard no-drop mouse cursor for Windows. It is not "counter-intuitive" in and of itself, but it is incorrectly configured here. The center of the no-drop cursor is supposed to be its hot spot. That is standard Windows behavior.

In reply to by sideways

What is standard, is that if you move the pointer over an illegal element it changes to the circle with a slash through it. What would be better would be something similar to what happens in a text document. Drag the item and if the pointer is over nothing it would highlight a reasonable location showing where releasing the button would drop it. When the pointer is over an element that it can't be dropped on, it becomes a don't drop cursor. When the pointer is moved off the item, it changes back to an arrow and highlights a reasonable drop space. In the case of dragging an item to text, it should hightlight the same position in a score you would get if you were using the mouse for note entry.

In this picture,

pointer destination.png

I would expect the rest in the Violin II measure with the blue note to be highlighted and the cursor to be a pointer with the element to be added nearby. Releasing my previous example of text would attach it to the rest.

Mike, you are correct, and I believe that the cause of the problem is the incorrect positioning of the no-drop cursor's hot spot.

When you drag the mouse hot spot over an item it acts as you describe. The problem is that the hot spot for the no-drop cursor is in the upper left corner of the image, so the red circle icon is incorrectly positioned relative to the actual mouse pointer position. Relative to where Windows thinks the mouse is positioned, the red circle appears to the right and down. The image that makes up this mouse pointer is a square, and this hot spot is in the upper left of the image, centered on empty space in the corner, not on the circle itself.

I have decades of experience programming in Windows, and I have designed and implemented custom mouse cursors in the past. I know how this stuff works internally. Trust me on this one, at least until someone fixes it and can explain the actual source of the problem. Then you can berate me for my lack of knowledge, if appropriate.

The issue that Marc raises is separate, and has to do with the way the drag operation is initiated in the MuseScore code, from what I can tell.

I really don't care how much experience you have programming for any platform. It doesn't prove to me you ever wrote a decent program. This isn't personal, just my general general opinion of anyone using their years of experience to tell me that their way is the best, the standard or whatever term you choose. Round cursors don't point at anything by definition. The user is forced to guess at where the destination of the pointer is. My suggestion, which probably is not be the only fix, makes the round cursor a non issue and, as I said, is used in text editing programs. I realize this isn't a text editor, but you can still use the same principles.

I will open another issue for the cursor and someone can fix it.

I am trying to point the programmers in the right direction here, discussing the internals. This particular round pointer is used everywhere in windows. Try dragging and dropping files in the File Explorer - actually I see that in the File Explorer it combines the circle with an arrow and text, very fancy.
This is the cursor that doesn't point at things, as you describe. It only shows that you cannot use the mouse at this location on the screen. It's an odd case, but that's how it works, when it is used.
This is Qt managing Windows native cursors or creating its own mouse cursors. I don't know which. Feel free to recommend a change in the cursor, but this cursor is not bogus in and of itself. It is a legitimate mouse cursor with a long history. This is a bug about the mouse pointer. I would prefer if a change to the cursor image was not made the central issue of this bug.

In reply to by sideways

The cursor is the root cause of the problem. No matter where you make the "point" on the round cursor it will cause someone confusion. A pointer with a point eliminates this confusion. The fancy one with the arrow and the don't drop is the one I was thinking of, but I couldn't think of where I've seen it in the past. I realize this one may be Windows OS specific and if so would make it impossible to use in a multi-platform environment.

In reply to by sideways

Also note: changing to a different cursor image does not necessarily fix this bug or make it moot. That all depends on how the new cursor is configured. Switching images might solve the problem or it might not. I don't know how Qt manages mouse cursors and I would prefer not to have to learn. I assume someone else is already familiar with this code. I'm trying to be as clear as possible.

In reply to by sideways

When you assume that changing the cursor image fixes the problem, you are assuming that this one no-drop cursor is badly configured, and that is the unique source of the problem. That's possible, but I have no idea how likely it is. There is a correct configuration for this current no-drop cursor, that is certain.

If you want to see this basic circle-slash cursor in action on Windows 10, try dragging and dropping text in your browser. I just tried this in Firefox and Chrome, latest versions of both. They both use a basic, black circle-slash that has a centered hot spot. The most reliable way to see it is to select a word of text, then try to drag it around. You should see the no-drop cursor most everywhere within the browser. Or find something else to drag, something that you can drop somewhere. You might find that the plain circle-slash isn't as bad as you think, because of the way it cleanly switches to a "drop-here" cursor when you pass over a droppable element. The badly configured hot spot makes it seem horrific, but it's a much paler shade of ugly than the MuseScore 3.0 beta portrays it.

I am not opposed to a different, "more modern", cursor image. I think it's an excellent idea. Neither do I know anything about the effort required to implement it in MuseScore, the priority of this issue, or the resources available to work on it. I am trying to be as clear as possible about all of this, so that an informed set of decisions and fixes can be made, so we can all be on the same page.

And just to be clear, when I talk about standards, I am not trying to force my opinion down anyone's throat. When I talk about standards, I am putting aside any personal opinions, and referring to official documentation (in this case from Microsoft) and widely used application examples. Following standards increases the usability of applications. Following standards is what allows different brands of web browsers to exist. Please don't demean the standards, no matter how supercilious the speaker or writer quoting them might seem. If they are misquoting actual standards, then call them on it, but please respect the standards themselves.

Here is design documentation from Microsoft regarding mouse pointers:
Scroll down a few pages to the Pointers section (no way to link within the page), and look at all the examples. You'll see a red circle-slash icon in the drag 'n' drop section. That is considered standard, which is probably why Qt has this setup. These docs give you some leeway in following standards too. Maybe "guidelines" is the correct word for some of these.

Here is programming documentation indicating that the basic circle-slash is a native, system-defined cursor (scroll down to OCR_NO). The fancier no-drop cursors in the Microsoft applications are not system-defined, standard cursors. They are custom cursors for those applications:

Chrome and Firefox certainly qualify as widely used, and it's telling to do the same test in Microsoft's Edge browser. The Microsoft browser has a fancier no-drop cursor. In general, Microsoft applications running on windows have features that few or no other applications have. They are the platform, they have an advantage. I'm not saying that MuseScore can't or shouldn't implement a fancier no-drop cursor, but I am saying that I have yet to see one in any non-Microsoft application running on Windows 10. Also note that the no-drop cursor in File Explorer is not the same as the one in Edge - they should standardize :-)

GitHub desktop uses a larger sized plain black circle-slash - soon they will be Microsoft too...
Apache Open Office and WinDiff use a medium size black circle-slash
Skype does not seem to support drag 'n' drop
I could go on...
These applications all use a basic circle-slash, in black, which is not the standard Windows color. As I said, there's leeway. It's also possible that in spite of the design docs, the system-defined OCR_NO cursor is black. Some of these apps are trying to be compatible within their app across operating systems, like MuseScore. That's a whole other wrinkle in the standards conversation.

There is nothing you can write that will make a round "pointer" magically point at anything. 30+ years of using computers since I bought my Apple II in 1986 or 7 has taught me to know what to expect from using a personal computer. When it's difficult to use, it's difficult to use. Dragging the circle to a skinny 8th or 1/4 rest is bad.

Dragging a clef to a note seems to be better, but this is because the pointer changes to an arrow when it arrives at a measure, you can then move the arrow to the note where you want to place the clef. The difference is that you can theoretically place the clef before any note or before the measure. Part of this is broke, but the overall act of placing the clef should stay the same when it's fixed. The experience of dragging the clef is very similar to dragging text into the box I'm currently typing in. It's a large target and the large round cursor is no issue until it changes to a pointer.

Version 2 was better.

Version 2 drag.gif

Mike, I don't want to continue this back and forth if it's going nowhere. You are not understanding me correctly, and neither of us knows the Qt implementation details, which are critical to fixing this issue.
I understand the issue of dropping on smaller targets vs larger ones. I agree that Microsoft's fancier cursors are an improvement - they wouldn't have created them otherwise. I'm not trying to convince you of anything but the technical facts. I can't be complete about all the facts because I'm not familiar with Qt and mouse cursors. But I have laid out the facts for Windows 10 in some detail. If you want to understand custom mouse pointers in Windows, read down the page in the design doc I linked to above.

fyi - I owned a Fat Mac (512KB memory) in 1985, the second model ever released. I was running running MOTU Performer version 1 with MIDI to an external keyboard. The Macintosh was the first widely used UI to use the basic circle-slash no-drop cursor because it was the first widely used UI with a mouse and drag/drop. These newer Microsoft cursors are Windows 10 stuff. I don't want to make this personal, but you shouldn't assume a lack of experience on my part. And try not to get too fired up about a custom, fancy cursor until you understand the implementation costs. You might be stuck with this basic no-drop cursor in MuseScore for reasons beyond your or my control.

Priority P0 - Critical P1 - High
Severity S4 - Minor S3 - Major

Tested and see that this is important, but not critical. I always see the cursor and understand where to put the element.

One more issue is that preview for some elements look really bad. It looks like we drag&drop an image, not an element (comparing to the visual feedback from dragging in MuseScore 2.3.2)

More of a side comment, but why does the cursor have to be positioned directly on top of the anchor point, anyway? The present issue is only a problem because almost the whole score is a "no-drop" zone, but wouldn't we be better off if that wasn't the case?

I have this currently cooking:


What do you think? It can still be improved upon, but I think this can go in as a hotfix / temporary improvement. It definitely makes dropping much easier for me when there is a "ghost" element picture. Not so much when there is only the cursor.

Fix version