Default location for saving files

• Dec 14, 2017 - 15:30

Why does MS not save revisions of documents (i.e., renamed files) in the same folder from which they were opened? Most Windows programs do this, which is why I'm in the habit of opening files and saving revisions of them without thinking about what folder I'm saving to. My MS files are kept in literally dozens of subfolders (one for each piece). Because of this standard behavior I'm constantly saving MS documents in the wrong folders. Is it possible that in the next revision an option could be added to make this behavior the default, for people like me?

Comments

• Dec 14, 2017 - 18:37

Different programs work differently, and note MsueScore doesn't only work on Windows.

MuseScore does something that a lot of other programs do, which is remember the last folder you saved to and by default go there when doing a Save As. This is very convenient when you have a single folder for a project and you are adding a bunch of scores to it that are new versions of ones that were previously elsewhere. For example, a "string quartet" folder that has string quartet arrangements of pieces that started life as a variety of different things.

Anyhow, because there is no way for MuseScore to know for sure what you want, it has to make a guess, and sometimes it will be right and other times wrong. Just get in the habit of making sure you are in the right fodler when using Save As.

Reply

• Dec 14, 2017 - 23:27

Thank you, Marc. I'm so in the habit of opening files from programs, and expecting them to be saved in the same folder they were opened from ... so may I ask, what is your process for opening/saving files?

I agree that the default behavior is convenient for saving a bunch of scores, but it doesn't seem so convenient if you're switching between different folders often, which is how I organize my files.

Is there an "easy/quick" way to change the folder to save to, other than going to Edit>Preferences?

Reply

• Dec 14, 2017 - 23:36

Files are saved in the same folder when you simply save them, and simply saving them is what I do 99% of the time. Doesn't matter if you are working on 1 files or 100 - if all you do is "Save" - which is all 99% of people do 99% of the time - then of course it gets to the same folder no questions asked. It's only in those relatively rare cases where one uses "Save As" that a question arises as to where you might want to save.

As I said, in these cases, sometimes you want it in the same file as the source, other times you want it the same place as other files you are working on for the same project, other times it is somewhere else entirely. Has nothing to do with whether you are switching folders often or not, it has to do with what your actual goal is.
The case I described is one where I'm switching the source folder often, but want the destination to always be the same (the String Quartet folder). That's actually a pretty common use model, so that's why a lot of programs do remember the last used folder - it really is helpful a lot.

But if you have some special reason to be saving a new copy of the file in the same folder as the original, then indeed you will need to tell MuseScore this, since it has no way of guessing this. Edit / Preferences is not actually relevant here. As I said, MuseScore remembers the last used folder, so regardless of what Edit / Preferences says, "Save As" will save to the last folder you actually used (for a "Save as" or similar operation).

Reply

• Dec 17, 2017 - 19:51

The problem with the idea of least astonishment is that different people are astonished by different things, depending on their backgrounds and what they happen to be trying to at the moment. As already explained several times, the current model works well with zero astonishment for some use cases. Other use cases end up being surprising indeed. If the behavior were changed, then the use cases that currently work well would suddenly be astonishing. There is no one-size-fits-all answer.

Reply

• Dec 18, 2017 - 17:03

I know of no other program that does not default to the location the current file was opened from, and I would also like to see this changed.

Reply

• Jan 17, 2018 - 03:00

Just did 3 tests. Not great statistically, but enough to show that folks are wrong about the ubiquity of the "Save As" behavior, and to support Marc's position (of non-ubiquity).

  1. Microsoft "Photos". This runs if I double-click a .png file on Windows 10. After a "Save As" to a different directory, then that different directory is sticky. I.e., if I open a different file that lives anywhere, "Save As" defaults to the aforementioned different directory. Even after a restart of the app.

  2. Eclipse. After opening foo.java, and doing "Save As" elsewhere, that different directory is likewise sticky, even after a restart of Eclipse.

  3. Microsoft Developer Studio. After opening foo.c , and doing "Save As" elsewhere, the different directory is NOT sticky. I.e., next time it defaults to the original directory of a file. There is an exception: if you do a second "Save As", on the same file, in the same session, the different directory is sticky, as all decent folk would agree is reasonable.

So it's 2 out of 3 for sticky "Save As". Not saying this is the best choice. Just sayin'...

Reply

• Jan 17, 2018 - 18:47

Thanks for the investigation and support :-). I agree it's not great statistically, and have no trouble believing it's not actually the majority of programs that work this way, but do appreciate the further evidence that this isn't some wacky thing we do and no one else does. It really is one common way of doing things, and a way that is very convenient (much more so than the alternative) for some particular workflows.

Reply

• Jan 17, 2018 - 19:16

In my job, when working on software products, it comes up every so often that we, the dev team, cannot decide what is the right behavior. Sometimes it's us wondering what customers will want, and sometimes it's prompted by customer feedback. Usually with a head-scratcher where there's no clear choice, we have a sudden realization: Make it a config option! That always settles it.

Of course that means extra work for the dev team, but it does solve the design problem.

Reply

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