Locked score unlocks by mouse interactions
Reported version
3.5
Priority
P3 - Low
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
- Open or Create a score
- Lock it (Ctrl-Shift-L)
- Click on the first measure and type "N" to try and enter note input mode
- Drag the score
Expected result: dragging the score keep the score in a locked state
Actual result: the score leaves SCORE_LOCK state
As locking a score is mainly used to prevent accidental edits by the mouse, it is rather ironic that precisely such an action results in unlocking the score.
Additional request: include a menu entry (perhaps under Tools or Edit) to make (Un)locking the score discoverable.
Comments
According to my test: Just dragging was enough to unlock the score.
In reply to According to my test: Just… by Ziya Mete Demircan
Yes indeed.
Step 3 was only there to confirm that STATE_LOCK was functional and does kind of work.
One of the main purposes for the lock score function was in response to teachers who did not want their students to edit their homework. Making this feature more discoverable would defeat the purpose.
In reply to One of the main purposes for… by mike320
Interesting angle.
The one I'm coming from (and the poster that triggered this) is where the score is distributed for the choir and the members should be protected from accidental changes due to dragging it around. But they shouldn't be prohibited to change it at all and it mustn't be too hard to discover how to "unlock" the score again if they for example wish to scale up their voice staff in comparison to the others.
Another way to unlock: have 2 scores open, lock one.
Switch to the other and back to the locked one: it is unlocked now
Actual result: the score leaves SCORE_LOCK state
Seems you mean STATE_LOCK, don't you?
How is locking a score useful (like to prevent another user in a different session to accidentally modify it), it it isn't a score property that gets saved along with the score?
STATE_LOCK yes; read what I mean, not what I type :-)
For the choir use case it should be saved into the score (although as an in between workaround we could have a plugin to open a score and lock it in a single action).
Can't save it, as the score is locked, catch-22
In reply to Can't save it, as the score… by Jojo-Schmitz
This is not a problem. Locked score can allow save (and save as).
Locked is just to avid "accidental changes".
In reply to One of the main purposes for… by mike320
Semi-hiding an option to protect homework doesn't seem the right approach to me.
@frfancha just try it. As soon as you use Ctrl-Shift+L to lock a score all menus are disabled, so no way to save
Yes, I get that, and that is wrong.
You should be able to save including the locked attribute.
There is nothing corresponding to write to a score. It is a state, internally used by MuseScore (like edit, note-enty, play, etc), while doing certain operations, nothing that would be written to a score
In reply to There is nothing… by Jojo-Schmitz
Again I get that.
One of the discovery done through this thead is that having that "locked" attribute as a true piece of info saved in the score could be useful.
In reply to Again I get that. One of the… by frfancha
By the way, having it as a true attribute would most probably simplify the code responsible to check the locked state and therefore solve all the bugs discovered here
Just a note that there is a different form of score locking implemented for the purpose of the score comparison tool, so make sure you can't edit the "last saved version". I briefly looked into"productizing" that (perhaps by incorporating that code into the existing lock command). First attempts were promising but there were some bugs I couldn't immediately solve, and I had too much else going on to continue. Still do, unfortunately.
Reading the original forum issue, a readonly score is requested but the best MuseScore offers is a locked score which is also far too easy to unlock ;-). The readonly score is where @Marc Sabatella is referring to?
popped up in the facebook user group: https://www.facebook.com/groups/musescore/permalink/5523921904300749/
In a future Musescore UI for the score lock feature, perhaps the "Mark as Final" feature in Microsoft Word might be a relevant model. Once set, the UI clearly shows the lock, but ANY user has the ability to turn off the lock and edit.
I'm looking at implementing this in v4.
I don't intend to add any additional functionality but my assumption is that in lock mode:
a) the only way to make ANY modification to the score is to first explicitly unlock it
b) all commands that do not modify the score should still be available, including save, selection commands, copy, pan, zoom, navigation commands - the only exception would be "mode change" commands like "note entry mode"
c) click & drag in lock mode should always pan the score regardless of what you click on
That's somewhat different to what we have now where
a) you can still modify/add elements via the palette even in locked mode
b) you can modify element/staff properties via the inspector or staff properties dialog even in "locked mode"
c) click & drag auto unlocks
d) piano roll editor still allows modifying score (NB this is being implemented currently for v4)
e) various context-menu commands like "split staff", etc. are still active
f) quite a lot of non-score-modifying commands are unavailable (e.g. save, select all, page up/down etc.)
The main challenge will be still allowing the inspector/properties panel and e.g. "staff properties" dialog to be useful without allowing them to make modifications.
Dylan’s proposal sounds very sensible.
Pretty much agree with the fixes as proposed by Dylan.
I could probably even live with a blanked out inspector and no staff properties for a locked score if that is easier to implement than a readonly version of those things.
In reply to Pretty much agree with the… by jeetee
I'm hoping Qt Quick/Qml has an easy way of disabling the whole panel!
I like the idea that "lock mode" by default hides all the dockpanels that aren't useful. It could even automatically hide unprintable stuff etc., in other words it's more like a "print preview" or a "score reading" mode that's intended for performing from etc.
Either way it's not going to be trivial to do well - what MU3 has at the moment doesn't seem worth all that much, other than the beginnings of a useful concept.