current mscore/file.cpp
It seems to be undergoing some changes recently, and I am at the same time merging my code with the latest master. I notice two spots in particular that seem possibly temporary in nature.
First, this printf() is temporary, right?
https://github.com/musescore/MuseScore/blob/100d297e54512c068386431c046…
And this bracketed pair of commands doesn't need braces, does it? Or is it temporary or something intentional?
https://github.com/musescore/MuseScore/blob/100d297e54512c068386431c046…
One more thing: I placed a comment about awkward variable naming in the SVG export code. It seems that the overlapping names have been changed/fixed, and the comment no longer applies. But I'm not certain, maybe there is more work to be done to complete the changes. Here is the comment, which I think can now be deleted:
https://github.com/musescore/MuseScore/blob/100d297e54512c068386431c046…
Comments
I have noticed something else that looks like a bug:
https://github.com/musescore/MuseScore/blob/100d297e54512c068386431c046…
There is no variable named "settings" anymore. It was renamed to "set", and it is scoped inside braces above this line, so it's not in scope here anyway. I don't know why this compiles, but it seems to be using a system-wide variable of some sort.
See here too:
https://github.com/musescore/MuseScore/blob/100d297e54512c068386431c046…
In reply to I have noticed something… by sideways
settings is a system wide global variable, the split here betwen set and settings indeed liooks like a bug, unless one is meant as a temp override only?
The other issues should get fixed in the due course.
In reply to settings is a system wide… by Jojo-Schmitz
Yes, that's why I focused on "settings" as the possible bug, and asked about the other things being temporary.
But I'll have to debug to see what exactly is going on with "settings" because of the one spot where the "set" variable is out of scope.
In reply to Yes, that's why I focused on… by sideways
as said earlier very like my screwup, so
git blamemight show this, but also hint at the commit and hence to the exact changes that had been done there, which in turn might clear up what the actual problem is thereIn reply to Yes, that's why I focused on… by sideways
The code prior to your MSVC changes is the same as my pre-merge code. The code already had the scope problem with two variables named "settings", one declared inside the braces of the if(), and the other below using the global. This is either a very old bug, or a very old feature, or a very old bug that has no negative consequences. I think you need to look into this and see what the effect is. You will understand the context much better than I. I only mess with this file for SVG exports. Or maybe @lasconic will understand it best.
In reply to The code prior to your MSVC… by sideways
Also note: my branch of MuseScore modifies some of this code and always uses a local QSettings variable, never the global one. So only using the local variable works fine, AFAICT. I don't know why the global variable exists at all, but maybe you do.
In reply to The code prior to your MSVC… by sideways
Please file an issue so it doesn't get forgotten
For now I'm just glad it wasn't my fault ;-)
In reply to Please file an issue so it… by Jojo-Schmitz
https://musescore.org/en/node/278712
In reply to https://musescore.org/en… by sideways
Thanks
Might have been me removing those overlapping variables, to fix MSVC compiler warnings. Well possible that I screwed something up in the due course, git blame or git log should show
In reply to Might have been me removing… by Jojo-Schmitz
I'm not trying to cast blame. I would't have noticed it if I didn't have to manually merge my code for this particular file. So I had to make those same changes as you, via copy/paste, and I noticed these oddities.
Should I file a bug, or will you take over from here?
In reply to I'm not trying to cast blame… by sideways
Please file a bug
In reply to Please file a bug by Jojo-Schmitz
I'm going to wait until I can debug and step the incorrect variable names, just to see what they are at run time. As you know from the mailing list, I'm in the middle of updating my build setup. Once I get it all up and running again I'll step it and submit an issue for the "settings" variables, as appropriate.