Toolbar item states are incorrect after applying preferences
Summary
If the user goes to Edit | Preferences and then applies the preferences, the states of one or more of the toolbar items can become incorrect.
Steps to reproduce
- Go to Edit | Preferences, switch to the Note Input tab, check the Enable MIDI input checkbox, then click OK.
- Open any score.
- In the File Operations toolbar, set the zoom to Whole Page and the view to Continuous View.
- Observe that the zoom and view both change accordingly.
- In the Playback Controls toolbar, make sure that the Toggle 'MIDI Input' button is turned off (not pressed in).
- Test MIDI input and observe that MIDI input works correctly.
- Go to Edit | Preferences again and OK.
- Observe that the zoom toolbar item has been reset to 100%, the view toolbar item has been changed to Page View, and the Toggle 'MIDI Input' toolbar button has been turned on (pressed in).
- Observe that the actual zoom and view of the score do not change, despite the new state of the toolbar buttons.
- Test MIDI input again and observe that it doesn't work, despite the new state of the toolbar button.
Expected behavior
Toolbar item states are unaffected by applying preferences.
Actual behavior
One or more toolbar item states are changed for no apparent reason.
Discussion
There are two different underlying causes for this issue. The first one applies to the two File Operations toolbar buttons: When preferences are applied, these toolbar buttons are actually destroyed and recreated, but the new toolbar buttons are not initialized to match the states of the old ones.
The second one applies to the Toggle 'MIDI Input' button: Its state becomes incorrect because its state is not being kept synchronized with the state of the Enable MIDI input checkbox on the Note Input tab of the MuseScore Preferences dialog.
Version number
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.12148, revision: b5c26d1
Comments
So is this a regression vs. 3.4.2?
IIRC the synchronization of the MIDI input button and the corresponding preference had been fixed (by me) not too long ago (in https://github.com/musescore/MuseScore/pull/5378, to fix #295443: Edit > Preferences > Note input > Enable MIDI input vs. Toolbar > Toggle 'MIDI Input', then there also was my https://github.com/musescore/MuseScore/pull/5900 to fix #303403: "Play Repeats" button does not reflect default repeat behavior)
Is this all maybe already adressed in https://github.com/musescore/MuseScore/pull/5922? (to fix #293203: Apply/OK of Preferences is very slow)
Or could/should get addressed there?
https://github.com/musescore/MuseScore/pull/6185
PR #6185.
Thanks for pointing out your previous PR, which was indeed a partial fix for this.
As far as I can tell, this issue is not a regression at all (although I checked only as far back as 3.4.2). It's just never been noticed before.
The code involved in this issue lives inside the
MuseScore
class and is executed after the preferences have been applied, so I think it's safe to say that this issue is logically separate from issue #293203: Apply/OK of Preferences is very slow.OK, so at least 3.4 then ;-)
And as far as my eyeballing showed, your PR does not collide with that other one
Fixed in branch 3.x, commit b9befdf75f
_Fix #306502: Toolbar item states are incorrect after applying preferences
Fixed some problems that caused the states of one or more toolbar items to become incorrect after the user went to “Edit” | “Preferences” and clicked “OK”.
Also renamed a pair of relevant getter/setter functions in the “MuseScore” class that were inconsistently and confusingly named._
Fixed in branch 3.x, commit 22d9345c66
_Merge pull request #6185 from Spire42/306502-toolbar-item-states-are-incorrect-after-applying-preferences
Fix #306502: Toolbar item states are incorrect after applying preferences_
Fixed in branch 3.5beta, commit 01b8867cdb
_Merge pull request #6185 from Spire42/306502-toolbar-item-states-are-incorrect-after-applying-preferences
Fix #306502: Toolbar item states are incorrect after applying preferences_
Automatically closed -- issue fixed for 2 weeks with no activity.