Reset and set as style buttons remain enabled after toggling bold, italic, or underline on/off
Vague title, I know. The basic problem is that with bold, italic, and underline controls sharing a single "Reset" button (and the accompanying "Set as style"), they get their signals crossed - literally. Since underline is the last button hooked up in mapSignals,, it is the only one that works for "Set as style". The reset button itself works OK, but it isn't enabled/disabled properly - it should be enabled if any of the three values are not default.
I was poking around today at a solution, the signal problem is easy enough, but enabling/disabling is trickier without more re-architecting than I felt comfortable with.
FWIW, the bold/italic/underline controls share a single reset for most text styles, but for tuplets, each gets its own, and same in Format / Style (most if not all the places these controls appear). I'm thinking it probably makes sense to just go back to having individual reset buttons everywhere (that includes "bend", "glissando", and the various text lines), although I do rather like having these controls shared.
Comments
Seems fixed now, thanks Werner!
It seems it was fixed in Format / Style, but not in the Inspector.
Although conceptually related, Bold, Italic and Underline can be enabled or disabled completely independent of each other, so it needs to be possible to reset each of them to its default value individually.
Consider this situation:
The user will try one of the following:
The situation is compounded if some elements are bold, some are underlined, some itallics, and the user tries to reset one of those properties after clicking "select all similar elements".
The same goes for all other styles that are conceptually related but actually independent:
If it is possible to enable or disable a formatting independently then it must be possible to reset it to default independently, otherwise users will have to resort to editing the MSCX file by hand, or resetting everything to default and then manually re-enabling all the things they need enabled or disabled.
> I'm thinking it probably makes sense to just go back to having individual reset buttons everywhere (that includes "bend", "glissando", and the various text lines), although I do rather like having these controls shared.
I agree having shared controls looks nicer, but hopefully my comment above will be enough to persuade you that individual reset buttons are necessary.
I like your suggestion of putting "reset to style" and "set as style" under a small drop-down menu. This would definitely help to reduce clutter, and would reduce the number of times keyboard users have to press the tab button to navigate the Inspector.
shoogle: the original bug is fixed. What you want is a feature request. The current code handles bold/italic/underline as one property. Its not easy to roll back this (> 6000 diff lines) and i like the current implementation more bc. its easier overall. Its a tradoff between simplicity and flexibility.
I guess I'll have to take your work for it that the new way of doing things is simpler, but this particular issue is not fixed:
Expected behaviour:
The "reset bold/italic/underline" button should be enabled if-and-only-if any of those properties are not at their default value.
The same is true for italic but not for underlining. However, underlining appears to have a different problem: the reset button stays correctly enabled with underlining but it doesn't get disabled again if the underlining is later removed. (I supposes this might be "by design" if this is considered manually overriding the style.)
Are you testing with a current build or with the beta? What you describe was true in the beta but for me is mostly fixed now with the changes made since then. Only issue I see is that the reset button stays enabled after toggling bold on then off, even after deselecting reselecting the text (that is, what you described for underline now happens for all three). But this is quite minor in comparison to the original problem, which again does seem fixed.
Yes, the first issue does seem to have been fixed since Wednesday when the Beta was released, which is odd because it was marked as fixed on Tuesday the day before the Beta was released, hence I assumed nothing had changed on this since the Beta. Perhaps the fix didn't quite make it in time to be included in the Beta.
So the only issue that remains is whether the reset button should become disabled after the user manually returns settings to the default.
FYI, the was merged to master before the beta release, but the beta tag is maintained separately and it was decided not to incldue this particular change in the beta - too big a change to risk that close to release.
No question in my mind the reset button should become disabled after the settings are manually toggled back, which is why I changed the title (and priority & severity) of this issue to reflect that.
The reset button has two functions:
1. set the property value back to default and
2. if the property value has a corresponding style then the property value is set to "styled"
If you manually change a styled property value then it is set to "unstyled". If you change back to the original value then the value is still "unstyled" and the reset button remains active.
A "styled" property value changes if the corresponding style value changes. A "unstyled" value does not change.
OK, and I see the other properties work the same.
Automatically closed -- issue fixed for 2 weeks with no activity.