MuseScore icon indicating copy to clipboard operation
MuseScore copied to clipboard

[MU4 Issue] Cannot type past decimal point in text size field

Open oktophonie opened this issue 2 years ago • 5 comments

Describe the bug In the Size field of the 'Edit Text Style' part of the Style > Text Styles dialog, one cannot type past the . in the value.

For example, if I want to replace an existing value of "12.00pt" with "11.25pt", I begin by selecting the value already there, and type "11", but any keystrokes after that are ignored. In order to change the digits after the point, I have to move the cursor (with mouse or arrow keys, to a position after the digit I want to replace, delete it, and I type a new one - moreover, I need to do this for each digit, because only a single keystroke will be accepted.

I have a suspicion this may be to do with a restriction in place to allow only two digits to be entered, to keep the values below 100, or something. In other words, it's a limitation on how many digits can be typed, not anything specifically about the dot itself. If I want to type "1.25" into the Line Spacing field, for example, I can type "1.2", but the "5" will be ignored.

https://user-images.githubusercontent.com/20604032/189478214-7c55ed21-f3c9-490e-8011-89261a5d43b5.mp4

I am not sure if there are not other fields that suffer from a similar problem; most of the other sections of the Style dialog seem to be OK. I do remember this being a more prevalent annoyance in 3.6, though.

See https://github.com/musescore/MuseScore/issues/13276 for why this can be doubly annoying (the rerendering of the score with each changed digit being potentially very slow).

oktophonie avatar Sep 10 '22 09:09 oktophonie

You can type past a '.' just fine, but yes, as you say, you can't have more than two decimal places after the ".", so you need to remove some of the existing characters first ("overtype" mode doesn't work either, strangely). While annoying, if it's the same in v3.6 and given this is QWidget-based code that I expect will be rewritten using Qt-quick/qml, I doubt it's worth fixing at this point.

wizofaus avatar Sep 11 '22 04:09 wizofaus

I think we can bump this to dev without the need for a design.

Tantacrul avatar Sep 15 '22 21:09 Tantacrul

But it would be good to have a general principle around field validation - personally I much prefer field validation to be done after exiting the field (tabbing/clicking away or when clicking OK/Apply/Save etc.). And as I said, I don't think it makes sense to fix the existing QWidget-based code as I assume that will all be replaced with Qt-Quick/QML style dialogs in the near future.

wizofaus avatar Sep 15 '22 22:09 wizofaus

I think @wizofaus has a point here. If this happens in Qt Widgets dialogs only, and the behaviour is similar to MS3, I'm not sure if this is worth a lot of effort. And since the customizability of Qt Widgets is not always great, we might not even be able to change this. But it might be possible...

cbjeukendrup avatar Sep 15 '22 22:09 cbjeukendrup

The one field that was always a source of major complaints and frustration in MU3 was the Staff Space size setting in Format / Page Setting. Ridiculously hard to type anything at all into that field, and the issue was compounded by a way-too-big default step value for the spinbox. Aside from that, though, most fields in most windows behaved relatively well. The fields that take decimal values in the style dialog in MU3 are certainly worse than average, but somehow not as bad as the staff space setting, and aren't as commonly used, so we rarely got complaints.

Now, I have no idea if this is related, but since the question of other widgets came up - something seems strange with keyboard input into spinboxes in the Properties window. Sometimes it works great, other times I can't type anything at all. For example:

  1. click a note or rest in a score
  2. open Appearance in Properties
  3. click in the horizontal offset box
  4. type in a new value - say, 1.5
  5. without closing the Appearance pane, click another note or rest
  6. click in the horizontal offset box again
  7. now try to type an offset

For me, 9 times out of 10, I can't - keyboard input simply isn't accepted at all. I suspect this isn't related, but you never know, so I thought I'd mention it here. And I'm happy to open a new issue if others can reproduce and agree it's not related.

MarcSabatella avatar Sep 15 '22 22:09 MarcSabatella

@oktophonie the original issue appears to be solved, perhaps by #15107

HemantAntony avatar Jan 22 '23 04:01 HemantAntony

True that!

oktophonie avatar Jan 22 '23 09:01 oktophonie