PNG exported with overwrite-avoiding name and overwrites without prompt if exported again
If you do a Save-As PNG, lets say on a file called XXX.mscz, it will prompt you to save as XXX.png. The trouble is, it actually seems to go and save it as XXX-1.png. I think this in itself is a problem. I understand it probably does it for multi-page scores, but for single page, this is kind of a pain. OK, anyway, if XXX.png exists, it will tell you it exists and ask if you want to overwrite. The trouble is, if XXX-1.png exists it won't prompt and will silently overwrite it.
Comments
BTW, this was on Mac.
Clarified title
I can reproduce.
1. Create score.
2. 'Save'.
3. Choose 'mscz'.
4. Enter 'XXX'.
5. 'Save'.
6. 'Export'.
7. Choose 'PNG'.
8. 'Save'.
Expected result: 'XXX.png'.
Actual result: 'XXX-1.png'.
9. 'Export'.
10. Choose 'PNG'.
11. 'Save'.
Expected result: Prompt appears about overwriting an existing file with the same name.
Actual result: File is overwritten.
Discussion: Is it Mac exclusive? Does it only affect PNG? It seems to be the same problem if you choose a different name for the PNG. I hope the title is better, perhaps?
Using MuseScore 2.0 Nightly Build (d5f451c) - Mac 10.7.4.
I did think about 'PNG exported with unnecessary overwrite-avoiding name and overwrites without prompt if exported again' :).
This affects Windows (Win7 32-bit) as well, using MS 1.2. Saving a file "foo.png" results in "foo-1.png". Resaving the file as "foo.png" never sees that name and silently saves as "foo-1.png" again.
Can someone suggest an expected behavior? Also for multiple pages.
How about check at the beginning if there are any files that would be overwritten, pop up a dialog listing them, and getting the user to OK it?
This is affecting unix platform as well.
I followed the steps to reproduce the bug on Linux Mint 13 (64 bit) and the same thing happens.
@lasconic :
Expected behaviour - I think for files with single page, we can save it as 'filename.png' . Also, if it already exists, then a warning box should pop up.
For files having multiple pages, we can save them as 'filename-1.png', 'filename-2.png' and so on ...
Also here, if any page already exists, then a warning box should pop up.
What do you say ?
parinporecha, Yes that would be an acceptable behavior. Of course there should only be one warning box for all the "page already exists" prompts. (Rather than displaying 30 prompts for a 30-page score).
I am working on this bug, and I have hit a bump.
For files having more than 1 pages, in the export dialog we show the file name as 'filename.cpp' whereas we are saving it as 'filename-1.cpp' , 'filename-2.cpp' and so on ...
Now I think, the problem is that the qtfiledialog (saveScoreDialog) takes the file name ( which here, is 'filename.cpp' ), and by itself returns a warning box if it is already present there. It's all inbuilt ( plz correct me if I am wrong. I ran the debugger a lot of times, still i am only seeing qtobjects, qeventloops in the backtrace ).
There are 2 solutions which i can think of -
1) So, unless we show the user the file name as 'filename-1.cpp' ( we only need to check for the first page ) , qtfiledialog can't know if the file is already present or not.
2) The other way is to continue showing the file name as 'filename.cpp' , and we manually search the directory for duplicates and manually show a warning dialog.
Please tell me your views, and other solutions :)
#1 is not a proper solution because it would not check the existence of filename-2.cpp. You should never delete any file without warning the user. Furthermore, if they enter filename-1.cpp, does it mean they expect you to create filename-1-1.cpp, filename-1-2.cpp etc?
#2 sounds better, but is still crap because they can enter filename.cpp and unexpectedly find you created filename-1.cpp, filename-2.cpp
It's one of those scenarios that ideally should have a custom dialog. Whether you have the time to do it is another thing. Maybe something like they choose the directory to create the files, and in a text field they enter the "name" of the files: "filename". Then a dialog box tells exactly what will happen in terms of files getting deleted and files getting created. Then they OK it.
Also, one further point, if the directory contains filename-1.cpp, filename-2.cpp, filename-3.cpp, but the current export is going to only overwrite filename-1.cpp and filename-2.cpp, I think filename-3.cpp (and filename.cpp) should be deleted too because otherwise its very messy in terms of figuring out what you just exported. All these details should be at least available to the user so they know what is going to happen.
I don't think you mean .cpp but rather .png?
Jojo-Schmitz,
sry, that was a typo. I meant 'filename.png' and similar
What about something like this. The browse button would open a "choose directory" window.
Option 2 in parenporecha's proposal would be completely acceptable. This is how PNG export works in Adobe Acrobat. I certainly wouldn't recommend that MuseScore delete PNG files for pages that you didn't ask it to touch. If a user wants to see only PNGs for latest pages they can sort the folder by creation date or save them to a new folder.
Creating a custom export dialog seems a lot of effort (including documentation, additional menu items, translations, etc) just to inform the user that page numbers will be appended to the filename. There is little benefit to telling the user ahead of time. The user is still able to find the file in the expected location since it sorts to the same place alphabetically. (An exception might be right-to-left languages, but I don't know enough about file systems in those languages to comment on that).
Finale does have a special graphics export dialog (screenshot attached), that offers several options. Oddly they make you go through three steps just to open the dialog . I prefer the simplicity of MuseScore's current export dialog (where all the file formats are accessible from a single dialog).
Custom export dialogs often add extra clicks to accomplish the equivalent task. For example in Lasconic's mockup you have to select a folder (which at least on Windows is not as familiar as selecting a file location), click OK, and then you still have to press Export. The user also has to process and interpret the additional options such as "File prefix" (a setting they are unlikely to want to change, particularly not every time they export a file). In the past we have kept export settings in the Preference panel.
I think its extremely confusing if you are exporting it several times, then you have old pages lying around from a previous export and you can't tell it was part of an old export or not. Yeah sure you CAN go look at the timestamps and nut it out, but its really ugly and messy. Maybe what you put into the dialog should always be interpreted as a folder/directory, and it dumps it all together that way. If the folder exists it is nuked first (after confirmation). It would probably be a lot neater.
For single page scores, we save it as 'Filename.png' , instead of 'Filename-1.png'.
The qt file dialog takes care of duplicates and shows warning dialog by itself.
If everyone agrees, then this matter is solved.
For multiple page scores, i think we can show a custom dialog like -
![1362573597943.png]( "1362573597943.png")
When the user clicks 'Yes' those files are overwritten,
When he clicks 'No', he is taken back to the export dialog, where he has to specify another name.
The only problem is we cannot show this dialog simultaneously when export dialog is shown. Because the export dialog is inbuilt, this dialog will only be shown after user clicks on 'Save'.
Plz tell me your views
parinporecha, The dialog is OK but instead of "Yes" and "No" buttons it is usually better to label the buttons with verbs that describe the resulting action. For example buttons with the labels, "Replace" and "Cancel" mean that the user doesn't have to read the whole dialog every time they see it (to remember if "Yes" is the right button or "No" is the right button).
This practice is mentioned briefly on the relevant Wikipedia page , and in more detail in this random blog post . Microsoft is notorious for including Yes/No dialogs for potentially destructive actions (such as a confirmation to save or discard a document) but seem to be moving in the right direction (think of the confirmation dialog to copy and replace files in Windows Explorer in recent versions of Windows). In old versions of Windows I've even seen Yes/No dialogs that didn't actually ask a "Yes/No" question, forcing the user into a nerve-racking gamble over which button is more likely to destroy their data. Apple has a better track record for embracing and following this principle (think of their standard "Save"/"Don't Save" dialogs).
David Bolton,
No problem, i'll change it.
fixed f6616643be
Automatically closed -- issue fixed for 2 weeks with no activity.