Page Settings: staff space (spatium) control pads input before user has finished editing
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
Steps to reproduce:
- Go to Format > Page Settings
- Double-click inside the staff space control to highlight the contents.
- Begin typing a new number (e.g. "1.2")
Expected behaviour:
- You will be able to finish typing "1.2".
Actual behaviour:
- As soon as you type a digit the input is instantly padded to 3 decimal places (e.g. "1" becomes "1.000") and it is not possible to type any more digits (except the decimal point for some reason).
Interesting quirk:
- It is possible to finish typing the value if it is identical to the previous value.
Tested in:
Fix version
4.0.0
Comments
There are, I think, a few other places where I've seen this, but this one is indeed the most annoying.
Work around for 1.000:
1) Place the cursor in behind the period (1.)
1) Use the arrow key on your keyboard to place the cursor on the right side of 1.0
2) Delete the 0 and place the number you wish (e.i., 7) and it show 1.700.
3) Use the arrow key again to place the cursor behind the next 0, delete and type a 6: It shows 1.760
4) Do the same for the next 0. type and 4 and you get back to 1.764. NEEDS FIXING.
This is fixed in my PR, https://github.com/musescore/MuseScore/pull/4456, which should be merged this coming Wednesday.
The dialog box has some design changes, and a bunch of fixes that come with them.
see #280363: [EPIC] Page Settings: fixes and changes
Came up again in #290952: Stave space size awkward to edit
And the PR needs a rebase
The new PR is https://github.com/musescore/MuseScore/pull/4906.
And again (for record, reported one year ago...) :(
https://musescore.org/en/node/299343
FWIW, I have no real opinion on the rest of what is in the PR, but am quite sure this would have been fixed long ago if there were a simple easy-to-review-and-test PR that fixes this without making other sweeping changes to the file format etc.
In reply to FWIW, I have no real opinion… by Marc Sabatella
Yes, Marc, that is probably true! But no one cares enough about this dialog to spend the time. I don't have the time right now or I might submit a PR that is just my changes to the dialog, which is kinda messy internally. There are many fixes to be made. If you steal just the relevant dialog box code changes from my PR, you might find it faster for creating an isolated PR for just this dialog box.
I agree this issue is quite annoying and should be fixed. Also, after looking into the PR, it seems to solve a lot .
If there are no objections (@sideways ?) I'm willing to take this issue out of PR4906 and create a separate PR for it.
In reply to I agree this issue is quite… by njvdberg
Please, feel free. The changes to this dialog are largely contained in the dialog source file. One of the changes you won't want to include is the addition of Pixels as a unit. I gutted and almost completely rewrote the .cpp file, and you can keep most if that if you really want to improve the functionality of this dialog.
The actual behavior when trying to change the staff space is actual a QT5 issue. I tried the QT5 spinbox examples (both QT 5.9 and 5.14) and this shows exactly the same behavior. Also KDE applications (e.g. okular and dolphin) show behavior.
For me I only see 3 options now:
1) Leave it as it is (and just blame QT :-)).
2) Report the issue to QT and wait for a solution by them (which take quite a while).
3) try to come up with our own version of a spinbox having the required behavior.
For myself, I tend to go to option 1.
Any opinions?
Came up again at #320689: Format>Page Settings field are persnickety about accepting values entered.
PR got closed long ago, but issue seems fixed in Mu4
Automatically closed -- issue fixed for 2 weeks with no activity.