Open a MusicXML without changing should not trigger Save changes dialog on close

• Nov 9, 2017 - 21:05

At some version of MuseScore, the behaviour was changed. I appreciate that MusicXML is not the native MuseScore format, but if I didn't change a MusicXML file it should ideally not force me to go through the Save changes dialog on close.
This is a bit analogue to Excel, where if you open csv and not change it also doesnt' show a dialog on close.
The reason why it would help is that if like me you open and or reopen a lot of MusicXML files and close a bunch you have to go though a lot of obsolete dialog boxes.
Could the old behaviour perhaps be restored?


Comments

You are doing some kind of import operation in some way or another.
I think it is normal to ask whether you want to save this file as mscz (internal format).
The same applies to mid, kar, gtp, gp(3, 4, 5 ,X), cap (x), mgu,sgu, ove (x), scv, bww files.

Workaround:
When the dialog box comes out, press TAB and then Spacebar keys.

In reply to by Ziya Mete Demircan

Thanks for your reply Ziya. I usually use the keys already, but ideally I would not have to, as I have no changes to loose, I disagree it is normal to ask to save, even if it was not opened in the internal format initially. If I make one little change to it in MuseScore, then yes I would agree to pop the dialog. In this case I also see the "*" in the tab.

In reply to by joejoe_

Yeah, I couldn' t agree more. I even started digging into MS code to add a possibility to open "scratch" scores.
Background: I use MS as an MusicXML viewer for Music21. In my workflow that often means looking at small fragments of music. In the current setup that would open a new score for each fragment. I could close MS after each viewing operation, but that would result in constant MS restarts. In my experimental setup I use OSC to open scores on a second monitor, so having to mouse over to the other monitor just to close that anoying save-dialog really breaks my workflow.

In reply to by rmattes

Should be quite easy to implement (basically a one-liner), we did it recently for MuseScore 1.x files, which too were considered to be imported and thus needed to get saved, even if nothing got changed on them.
Only wih XML it really is a import, and the default should be to show the need to save thwm, so we'd need some setting or cmd-line switch (like e.g --xml-viewer) to change that to your desired behavoir.

Edit: the release notes have it as "•Don't autosave unchanged "imported" 1.x scores", and it was done to prevent the score properties to get changed after an autosave, so it was still visible that the score got created with a pre 2.x version, see 76eb0c8

In reply to by rmattes

Probably just need a setCreated(false);, maybe additionally a setAutosaveDirty(false);
And when adding an option, maybe make it a general viewer, not just xml, so something like --viewer-mode, also used for MIDI, GuitarPro, etc.
Or a `--silent' mode, not asking any questions on exit, nor on startup (like for corrupted scores)

In reply to by Jojo-Schmitz

Ah, I see - I misunderstood the _created property and used setCreated(true) (that's really a bad name so, with the current semantics I'd expect something like is_volatile or is_ephemeral).
Everything works as intended now for all kind of files. Now one can hack up a digital music stand with just a few lines of python and a remote control ;-)
BTW, I think there's a terrible bug in MSs OSC code. Will report later ...

In reply to by rmattes

I would not expect MusicXML specific behavior. I would only expect Save pop up when the dirty "*" is on the tab. So same solution as for old MuseScore formats would be the most logical I can think of: Whatever format opened: No change = Not dirty = No need to warn about loss of data = No pop up. Having said that, a command line argument might work for me specifically also, but perhaps it unnecessarily increases MuseScore complexity slightly.

In reply to by joejoe_

Yes, I agree. An imported file should not be marked 'dirty' until modified. The only (slightly) anoying behavior in my usecase: even small actions (such as switching from page view to continuous view) mark a score as dirty.
And there seems to be no (obvious) way to open imported files in continuous view.

In reply to by rmattes

Not sure what other small actions you refer to, but the view switch specifically should ideally not make the file dirty, as it is just a viewing action, not an edit action, just like a zoom level change doesn't make it dirty either. Your last comment I have also been thinking about it for a while. It would be nice if one could set a default view (page or continuous) in the Preferences box.

In reply to by Jojo-Schmitz

Yes, I'm aware of this. In my ideal MuseScore design this would be part of a (saveable) workspace/session.
That way one could use the same score in different contexts (i.e. editing, proofreading, performance ...) with different defaults.
Such a session file would also be the perfect place to store customized magnification/zoom levels, the lack of wich to me is one of the most unfortunate lacuna in MS's current user interface.

In reply to by rmattes

FWIW, page / continuous view was not always an undoable operation (which is basically the trigger for what marks a score dirty), but it led to a number of nasty bugs where if you performed an operation in page view then switched to continuous view attempted to undo it, really bad things would happen because there is not necessarily any way to restore the original state of the score. There might be other solutions that involve completely reimplementing how undo attempts to restore state in these cases. I think the nightly builds for MuseScore 3 may already do things differently in this respect in fact. Anyhow, it's not just on a whim that toggle page / continuous view represents a change to your score.

Do you still have an unanswered question? Please log in first to post your question.