Spinners don't have repeat function: only single-click

I am interested to know why you consider this to be a major issue.

The spin box is displayed in a different color depending on whether the property flag is set to STYLED (use the default value) or UNSTYLED (do not use the default value). QWidget::setStyleSheet() is used to change the color of the spin box. One side effect of this function is that it will interrupt any events to which the widget is currently responding. This only happens when changing from the default value.

If I may interject, the results are inconsistent. Holding the mouse click should either cycle through the values or not. I vote for cycling through the values. Since we have a choice of major or minor, I would agree major is the better severity.

I cannot reproduce.

Maybe OS specific, because works for me with green coloured values as well

The behavior is as geetar describes in Windows 10 and macOS 10.14.1. If the color of the spin box arrow is green, the value will only change once, no matter how long you hold down the mouse button. Afterwards, you can click-and-hold again, and the value will change continuously. The need for a second click is caused by the method that is used to change the color from green to black. That method is QWidget::setStyleSheet(), and it is called from InspectorBase::checkDifferentValues().

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4042, revision: af128b5 a couple of days old, but I've seen nothing that should have fixed it.

You can tell I'm holding the mouse button in the picture because of the yellow circle. Notice the spinner moves once if I hold the mouse button when the text is blue, but works as a spinner when I hold the mouse button after it has turned black. As seen in the picture, it doesn't matter why the text turns black, just that it has. To clarify, in the first example, I click and hold the top spinner and it changes once until I release and click the mouse again. I move the mouse to the bottom spinner and it immediately spins as expected because it is already black. I then reset the inspectors to show that the bottom spinner only moved once while it was blue, but worked as expected after it turned black.

@Anatoly, for whatever reason, the offset on a note starts as black, I would consider this a bug since the offset hasn't been changed like the offset for the text in my examples.

the offset on a note starts as black, I would consider this a bug
The green color only applies when there are style defaults. This is not the case for all properties. I would not consider this a bug.

Ok, then it's poor design decision. You should be able to click a button to put a notehead back where it belongs just like a text item. This is one of several examples of inconsistent behavior that will lead to confusion. Some of the others have been fixed.

You should be able to click a button to put a notehead back where it belongs just like a text item.
There is a button to do this, and it works. But not all properties are styled properties, and the green color only applies to styled properties.

Your distinction is nonsensical. The offset in text is blue until it's changed by the user while the offset on a note or note head is always black. This is inconsistent and adds to confusion.

As far as the reset button is concerned, I didn't see it because the inspector is so wide I make it narrower so I can fit more score on my screen.

Some properties have a button next to the reset button that allows the user to set the current value as the default for that particular style. This button is labeled with an "S". This "Set as style" button only appears when there is a style setting that corresponds to that property. I am calling these properties "styled properties", because that is what they are called. The green color indicates that the property is set to the style default.

I'm not understanding the issue. The distinction between which values are green vs black is hopefully clear enough - values that comes from style setting defaults are green (thus giving you the visual cue that if you want, you can change the values in style settings). All else is black. One could quibble whether this is the best method of indicating it, but that's better left to a separate forum thread.

Meanwhile, though, I find the arrows work just fine whether the value is green or black. There is a slight pause after the first change, then it continues, just as I expect, and again independent of color. Maybe something changed with the implementation of the new "set as style" buttons?

I will quibble, however, with the decision to make the default increment for the offset fields 0.2sp. It was previously 0.1sp. I often like moving things in 0.5sp increments, and previously I could get that directly using the arrows, now I need to type. Anyone mind if I change it back?

The issue is that sometime clicking and holding an arrow makes the value change once, sometimes it changes until you release the mouse.

OK, got it. Not about keyboard, but about clicking arrows. Got caught up in the subsequent discussion and missed that in the original description :-)

See also #287908: Dynamics: velocity change spinner not working properly for a similar report but one specific to one control that doesn't "fix" itself on second change the way most do.

Relates to #311174: [EPIC] UI/UX issues and suggestions