"no drop" mouse pointer badly positioned

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:
https://www.dropbox.com/s/r4i4h4f96kav6ro/MuseScore%203%20%283.0.0%20un…

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...

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.

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.

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.

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 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.

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.

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:
https://docs.microsoft.com/en-us/windows/desktop/uxguide/inter-mouse
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:
https://docs.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser…

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.

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.