Element Offset: spin box arrows not working properly

• Nov 21, 2018 - 16:14
Reported version
3.0-dev
Priority
P2 - Medium
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 6ba431b

Open the attached file (created in this nightly)

  1. Click on the Subtitle ("Op. 6"), say;
  2. In the Inspector, left-click and hold down on a spin box arrow for either the X-offset or Y-offset.
    Expected result: The value should increase continuously.
    Actual result: The value only changes by one step, then stops. You have to press again to continue increasing/decreasing the value.
  3. Increase the same value a few more steps, then press the "Reset to default" button.
  4. Now left-click and hold down on a spin box arrow again.
    Result: The same problem recurs.
Attachment Size
spin_box_issue.mscz 12.02 KB

Comments

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.

Status needs info active

The issue only seems to manifest when the colour of the offset value is green/blue—not when black.

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

In reply to by Anatoly-os

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.

spinner.gif

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.

In reply to by mattmcclinch

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?

Priority P1 - High P2 - Medium
Severity S3 - Major S4 - Minor
Status needs info active
Type Functional Ergonomical (UX)

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