Erratic behaviour when repositioning (text) objects or changing their offset values

[rgreen5]

Issue type

UI bug

Bug description

The behaviour of objects when repositioning can be unpredictable as can their offsets.

Steps to reproduce

1. Open the attached file.
   positioning_and_offsets.zip
   As you can see it consists of notes with fingering numbers in the default position.

2. Click on the first fingering.

3. Open the Appearance panel, and reduce the value of the vertical offset step by step.
   ACTUAL RESULT: The object initially moves upwards (as expected), but when it gets to -3 it suddenly flips downwards again. Then continues upwards.
   EXPECTED RESULT: The object should move smoothly in line with the user's expectations.

4. Now increase the value of the same offset.
   ACTUAL RESULT: As the offset moves back to zero the fingering moves closer to the note and at zero is exactly over the note – effectively disappearing from the user's view. You have to use "R" to reset the note back to its default.
   EXPECTED RESULT: When the offset is returned to zero, the fingering should be in the original default position (in this case, above the note).

5. Reset the position of the same fingering.

6. Now, with the Appearance box still open, use the keyboard UP arrow to move the fingering in the same way.
   ACTUAL RESULT: The fingering moves consistently upwards. However, at intervals it seems to stall even though the offset value (in Properties) is still changing.
   EXPECTED RESULT: Each push of the keyboard arrow should generate a movement.

7. Reset the fingering again.

8. Use the keyboard arrow to move the fingering upwards.

9. In "Appearance" press "Set as default style for this score"
   RESULT: As expected all the fingerings are updated.

10. Return the score to its initial settings.

11. Now use the mouse to drag the same fingering upwards.

12. In "Appearance" press "Set as default style for this score"
    ACTUAL RESULT: The adjusted fingering stays in its expected position but the other fingerings jump to an unexpectedly higher position (see screencast below).
    EXPECTED RESULT: Updated fingering should move to a position comparable with the adjusted fingering.

Screenshots/Screen recordings

MuseScore Version

MuseScore version (64-bit): 4.0.2-230640504, revision: github-musescore-musescore-769b3af

Regression

Choose option...

Operating system

OS: Linux Mint 20.1, Arch.: x86_64

Additional context

No response

[MarcSabatella]

FWIW, the fingering placement algorithms are extremely tricky to work with, since unlikely most other forms of text, they are actually positioned relative to the notehead and must be "faked" to appear at a particular distance above the staff.

In the first case above, probably increasing the offset should have no effect at all until the offset catches up to the actual default position relative to the note, which would be more consistent with how other text works. FWIW, it's basically the same in MU3, so not a regression.

In the second case, explicit offet 0 placing directly over the note - this is correct behavior. As mentioned, the actual point of offset is relative to the notehead. The only reason it doens't display that way by default is autioplace is moving it out of the way to avoid the collision, but when setting an explicit offset, as always, this takes precedence.

Probably the other behaviors are more or less unavoidable consequences of the way the offsets are calculated relative to the notehead, which is pretty much guaranteed to lead to weirdnesses. Especially with respect to style, since the offset actually need to be different for each note to achieve consistent height.

I would propose that for these fingeings that are positioned above the staff, they should be actually implemented that way, not relative to the notehead. This would be a project in itself, because of course other fingerings types do need to positined relative to the noteheads, as do these fingerings when there are multiple voices involved.