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

• Nov 9, 2017 - 21:56

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.

Reply

• Nov 10, 2017 - 06:07

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.

Reply

• Nov 10, 2017 - 10:04

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.

Reply

• Nov 10, 2017 - 10:24

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

Reply

• Nov 10, 2017 - 13:49

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)

Reply

• Nov 10, 2017 - 14:41

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 ...

Reply

• Nov 11, 2017 - 20:05

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.

Reply

• Nov 12, 2017 - 10:25

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.

Reply

• Nov 12, 2017 - 11:40

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.

Reply

• Nov 12, 2017 - 14:09

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.

Reply

• Nov 12, 2017 - 18:29

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.

Reply

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