#24908: Validate saved files and alert user

[krasko78]

Resolves: #24908

Initial commit to demonstrate the idea and start refining it.

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[krasko78]

Do we want to limit this to Windows users only?

[RomanPudashkin]

Do we want to limit this to Windows users only?

I'd rather keep it for all OS

[DmitryArefiev]

@krasko78 Can you restart builds please? Linux build is missing

[Jojo-Schmitz]

Non-staff-members can't do that

[Jojo-Schmitz]

But there is an issue with the translatable strings, like subsequent trailing whitespace, which the Linux build stumbles accross

Also a code style issue

[krasko78]

@Jojo-Schmitz How can I do the code style validation from inside Qt Creator or before I commit?

[Jojo-Schmitz]

The latter, running uncrustify locally, but I rather let GitHub CI let it do for me 😉

[krasko78]

@bkunda @RomanPudashkin @cbjeukendrup @Jojo-Schmitz @wizofaus
Here is the warning dialog for review:

[krasko78]

Gah, no, I still don't like it... But let hear everyone out and I'll edit it accordingly.
How about this one:

[wizofaus]

@Jojo-Schmitz How can I do the code style validation from inside Qt Creator or before I commit?

If you're on Windows I have a batch file that can both check and fix all modified files, though you need to install a specific version of uncrustify.
I hate having to wait for the github CI job to fail the PR.

[Jojo-Schmitz]

There's not much to wait, it fails quite fast

[krasko78]

It is building fine now and I am publishing the PR. Please make sure you've looked at the latest changes. Thanks.

[bkunda]

Thanks for tackling this problem @krasko78! Great to have a solution that will prevent this kind of file corruption.

My only comment has to do with the UI copy and dialog design. To better align it with our existing corruption dialogs, and to simplify the messaging, I'd prefer to see the following:

Then when "Show details" is clicked, the error message appears below (and the dialog expands accordingly):

As I understand it, when a score file gets filled with 0s, it's no longer usable and in all cases needs to be re-saved. In this case, the messaging should be much simpler, and we should just give the user a button that triggers the OS save dialog ("Save a copy").

For bonus points, the "musescore.org" hyperlinked text should point directly to the relevant forum: https://musescore.org/en/forum/6

Let me know if this makes sense!

[cbjeukendrup]

@bkunda That is not 100% accurate. I will explain the problem in more detail later today (right now omw to an exam 🙂)

[krasko78]

Btw, should we say "corrupted" or "corrupt"? I believe we should use "corrupt" when we want the adjective. Native English speakers please advise.