Allow score traversal while Style dialogue is opened
Merely a suggestion, but I personally think a simple and decent one that isn't really a question:
Allow the user to continue to traverse a score with the score setting dialogue open, especially:
+ Zoom
+ Grip and move
This way, the user would not be confined to the view that was set in place prior to opening up the dialogue. As it stands, the user might want to see a clef, but when opening the dialogue, changing the font or some other settings, the view might not be optimal to verify the results. Instead of needing to close the settings dialogue, reposition, then potentially re-open the dialogue for further changes, this suggestion as implemented would allow for a smoother experience during score preferences setting.
The idea should be fairly simple to actualize and might be something useful to do for a newer contributor to get their 'feet wet'.
Comments
+1 for this suggestion. Needing to close and re-open the style editor to properly explore the current style is inconvenient.
+1
+1
Now that there has been some positive feedback (almost forgot about this suggestion), I checked the code to see what could be done. Instead of trying to disable certain functions like inserting notes etc., I merely allowed the dialog to be non-modal, which is what allows for it to be "on top" since it has the main MS window as a parent, but not always having the focus. Only a few changes were required for this. I'll make a pull request, and if anyone wants to test it out before being possibly merged, check out its artifacts on github and/or make some comments.
https://github.com/musescore/MuseScore/pull/6845
Haven't done this before, but apparently MuseScore's github is set up to automatically produce build artifacts for open PRs now, so I think I can link builds for testing in here like this:
Windows build:
https://github.com/musescore/MuseScore/suites/1476535589/artifacts/2547…
Linux build:
https://github.com/musescore/MuseScore/suites/1476535587/artifacts/2547…
Fixed in branch 3.x, commit 7a15c452d5
_Merge pull request #6845 from worldwideweary/302990-AllowScoreTraversalWhileStyleDialogueOpened
Fix #302990: Set Style Edit dialog to be non-modal to allow score traversal when s…_
Automatically closed -- issue fixed for 2 weeks with no activity.
Update: although the alpha/beta has this ability, it looks like the actual 3.6 version won't because it allowed the user to naively switch scores while the dialogue was opened, and instead of adding to this PR by updating the dialogue accordingly when a score is switched (or alternatively disabling the ability to do so), it will more than likely get reverted. I probably won't be getting to that anytime soon, so unless someone changes something, this probably won't make it into 3.6.
Let's reopen it then.
https://github.com/musescore/MuseScore/pull/7204 is the PR that will revert that fix, to fix #315050: Style menu: does not refresh when you change score tabs, affects wrong score
Another problem that will occur is the following.
When you make changes in the style dialog, those changes are immediately applied. If you press OK, it just closes, when you press Cancel, the 'undo' functionality will be used to revert te changes.
So if you open the dialog, make some changes and then for example enter some notes in the score, strange things will happen if you press Cancel in the Style dialog.
So, to me, it seems too complex and error-prone to fix this in this stage before a release.
In reply to Another problem that will… by cbjeukendrup
Ideally, the style window should be completely refreshed when the active score is changed.
And when the style settings are "dirty", switching score must trigger a modal dialog forcing to cancel or apply the pending style changes to the score before it loses focus.
In reply to Another problem that will… by cbjeukendrup
@cbjeukendrup, Nice point about the undo situation.
Now that you mention it, this reinforces the idea that a "lock score" function would be acceptable, as with people speaking about this in https://musescore.org/en/node/294428, https://musescore.org/en/node/74166 as examples for wanting read-only mode (albeit as a score property saved in scores, but if this function existed, also have it internally accessible).
What I mean is, if MuseScore were to get this implemented in the future, we could temporarily insert the currently opened scores as "locked"/read-only mode. And then, if we also updated the Style dialogue when/if the viewed score is switched and demanded a "save or cancel" option as mentioned by @frfancha, i think these two would take of the issues with being able to traverse scores while having the Style dialogue open.
I don't think lock score has any link with the current issue. Why would a user want in any way to lock a score while navigating in MuseScore to edit different files? Have you read my previous post which I really think gracefully solves the current problem (well when a PR will exist)
In reply to I don't think lock score has… by frfancha
frfancha: As cbjeukendrup mentioned earlier, there are a few problems, not just one. I won't answer your question as to why someone might want to make a file read-only or locked, as that's not pertinent to this particular issue (but the linked posts might give some ideas). May I ask rather why you do not think making scores temporarily "locked" so as to disallow edits while the Style dialogue is open would not solve the particular issue he mentioned when pressing "cancel" if the user edited the score in the process?
It seems to me that it would be safeguard against the problem he mentioned, but if I'm misunderstanding, I'm open to correction or being provided a better approach.