Cancel does not undo scaling change
Go to Layout, change scaling.
Apply. (Score changes).
Cancel.
Expected - score will revert.
Actual - score remains rescaled.
Workaround - Undo reverts.
Do you still have an unanswered question? Please log in first to post your question.
Comments
Cancelling out of a dialog doesn't undo applied changes. Not in MuseScore, not in any other program; Cancel simply means, don't apply non-applied changes and close the dialog.
That being said, it would be nice if changing those values would take immediate effect, so you can actually play with them and see what works *and* still be able to cancel out of there if no change works as desired.
I think this is already the case in the 3.x development branch, so that would give those buttons a clearer purpose.
In reply to Cancelling out of a dialog by jeetee
Well, there are definitely *some* programs in which Cancel reverts changes already applied. It's considered standard behavior according to Mac OS design guidelines apparently. But on other systems it's at least as common for Cencel to only discard changes *not* yet applied.
In the current 3.0 development version, changes to some dialogs do indeed apply immediately - no Apply button needed (or, indeed, present at all). But Cancel doesn't revert the changes, either, so that's not good.
In reply to Well, there are definitely by Marc Sabatella
That's not good at all.
In reply to That's not good at all. by Isaac Weiss
Perhaps a "will not undo" button? :)
In reply to Cancelling out of a dialog by jeetee
Further summarizing what I feel the dialog buttons should do (editorial note: 90% Windows user speaking here, no noteworthy experience with Mac over the past 10 years).
OK 'Apply' all pending operations and close the dialog.
Apply 'Apply' all pending operations, keep the dialog open.
Cancel Close the dialog, discard all pending operations (as in: don't Apply them)
In order for this to work well, a lot of changes made into a dialog should come into effect immediately (especially style options) so one can make a decision on whether to keep (apply) those changes or not.
Each time all pending (=non-applied) changes are applied (be it by an Apply or OK button), they should count as one undo-redo action. Pressing cancel rolls back all changes that had taken effect but weren't applied.
This behavior is important in dialogs that allow traversing the score as well (measure/staff properties) in which it would be wierd even to rollback changes in one measure/staff that had been applied because you're cancelling out of the dialog that by now focuses on another measure/staff.
In reply to Further summarizing what I by jeetee
Well, to me Apply is the same as OK, with the difference that I stay in the Dialog and can make furter changes, so Cancel should only revert whatever has changed since last Apply (if any).
To revert the changes before the Apply, there is Undo/Ctrl+Z
In reply to Well, to me Apply is the same by Jojo-Schmitz
Exactly
In reply to Exactly by jeetee
Ah, now I see, 'pending operations'...
In reply to Ah, now I see, 'pending by Jojo-Schmitz
Some more information:
The General Style dialog is the only one from which the "Apply" button has been removed, and changes are reflected in the score in real time as you change the settings in the dialog.
However, clicking "Cancel" actually undoes the applied changes.
However, pressing [Esc] does not! The changes are applied instead of cancelled, and don't appear in the Undo history. 3.0 sometimes (not always) crashes on an "Undo" following this.
In reply to Some more information: The by Isaac Weiss
Hi.
Do you not think this deserves its own bug report?
In reply to Hi. Do you not think this by xavierjazz
See #110241: Regression—pressing [Esc] in General Style dialog applies all changes instead of cancelling.
In reply to Some more information: The by Isaac Weiss
That's a bit scary, actually. I use ESC as a way to quit a dialogue window quite often; it's a reflex that won't be easy to change.
I am starting to sense a need for a 'consistency review' of the ways the program reacts to the various user methods of ending a dialogue. There needs to be ONE standard of behaviour upon which the user can depend for ALL dialogues and methods.
In reply to Some more information: The by Isaac Weiss
As to the crash I mentioned, see #110926: Crash on undo/redo after changing staff distance.
I've noticed this at various times for a number of different functions; but as long as the changes can be reversed with CTL+Z or 'Undo' after the dialogue window is closed, I don't consider it a real problem. Yes, the word 'cancel' implies (or used to, before the computer age) that whatever was done should become as if it never happened when the user subsequently 'cancels'...but the semantics of 'apply' and 'cancel' are now seemingly at each other's throats.
In the legal world, this is an important distinction, because if someone signs a contract with the promise he can subsequently cancel it, he will be most upset to learn that by committing some other act (say, opening the shrink wrap to see if the actual product suits his needs; sort of the way we click 'apply' to see if the revised formatting fits the page properly) he has 'applied' the terms of the contract and can no longer cancel.
I must admit that until I noticed this behaviour in MuseScore, I was operating under the general belief that if I clicked 'cancel' on ANY dialogue window, NOTHING would have changed on the base document or window since before I opened that dialogue. I think that MuseScore is the first program I've seen with an 'apply' button in addition to the standard 'ok'.
BTW--I could be wrong, but IIRC being able to undo a change that is applied to all parts is NOT possible. I remember accidentally clicking 'Apply to all parts' instead of 'Apply' after having inserted part-specific text in a header box ('Sonata in C minor/Alto recorder') and then having to go back and change the header boxes for the OTHER parts--Soprano, Tenor, Bass, Great Bass, Cello, Harpsichord--manually, one at a time. Very annoying.
I will check this later tonight on a test score. Too many windows and tabs open at present to load another one.
In reply to I've noticed this at various by Recorder485
To me this is the critical aspect: "but as long as the changes can be reversed with CTL+Z or 'Undo' after the dialogue window is closed, I don't consider it a real problem."
I agree.
In reply to To me this is the critical by xavierjazz
I can't see a major problem, but I do see a problem
In reply to I can't see a major problem, by Jojo-Schmitz
Yes.
In reply to Yes. by xavierjazz
Perhaps the solution would be to add an 'Un-Apply' (Undo) button to the dialogue window? Or possibly make the 'Apply' button turn into that once it is clicked? (That would eliminate the visual clutter implied by adding yet another button.)
It IS convenient to be able to experiment with provisional changes before they are made final....
In reply to Perhaps the solution would be by Recorder485
I'm used to lot of programs in the Windows world, and the behavior of MuseScore described here is exactly the standard one: cancel revert the changes in the dialog box not applied yet (to reverse applied changes you must use undo).
So there is no problem at all.
A thing that could be done to make the interface more explicit is to disable the buttons apply and cancel when there is no pending changes (and therefore nothing to apply and nothing to cancel).
In reply to I'm used to lot of programs by frfancha
Yes, this is indeed comon in Windows and Linux applications. At least for Apply: i'm not accustomed to seeing Cancel deactivated, nor do I think IU'd like that. Hitting Esc immediately after opening a dialog by mistake is a common operation you don't want to mess with.
In reply to Yes, this is indeed comon in by Marc Sabatella
Yes you're right, in fact Cancel does 2 things: revert not applied changes if any, and close the dialog. Therefore it can't be disabled.