Use flat and sharp symbols for key signature tooltip

• Feb 6, 2014 - 01:18

In score set-up and the 'Key Signature' palette, the tooltips for those featuring flats or sharps use b or hash respectively.

Use flat and sharp symbols for key signature tooltip.png

Can the proper symbols be used?


If it is in a ui file (and think these are), it may be possible to change, as these are in UTF8, I think. If is it is a cpp file this may not work, I believe these need to remain plain ASCII. What would certainly work is to make that change in the translations, these files definitly are UTF8.

I assume Qt strings support some form of standard escape sequences to specify Unicode characters. A brief search suggests it isn't as trivial as one might hope, but can be done by calling some sort of conversion function.

These strings are in libmscore/keysig.cpp and mscore/transposedialog.ui. In either case it can easily get fixed in the translations, but I'm unsure how and whether to change it in the .cpp resp. .ui file...

Done now in the translations for en_UK and en_US.

Found a couple more files, awl/utils.cpp, libmscore/chordlist.cpp, libmscore/utils.cpp, mscore/editpitch.ui, mscore/editstaff.cpp, mscore/editstringdata.cpp and mscore/importmidi_opmodel.cpp
I've modified all but chordlist.cpp (I think it serves a different purpose?) to use the UTF8 characters ♭ and ♯ directly and it compiles, builds and looks fine.
In the .cpp files we could use '\u266d' instead of ♭ and '\u266f' instead of ♯, if the compilers on Mac or Linux don't like UTF8 chars, which I can't check...

it would be a lot better to use ASCII only in CPP files. It could work or not depending on the compiler and testing on the 3 desktop OS we support is not enough. MuseScore is also compiled for other OSes (BSD, solaris like etc...) with other compilers. There is currently nothing done to specify the encoding of the file to the compiler during the build process... so I would favor the use of L'\uXXXX' notation in CPP files and stick to ASCII

Another important point... if b and # were used before it's because some system font didn't have the flat and sharp symbols and so tooltips were displaying ? or square. It could still be the case on old OSes like WinXP...

I agree on the \u issue, it just doesn't look as nice in the source code as with using UTF8 directly.
Not sure b and # are an issue with Win XP, with MuseScore, as I believe we use our own fonts (FreeSans, FreeSerif, Mscore/Emmentaler, Gonville, Bravura) internally, don't we? Will check later (still have a dual boot, Win7 and WinXP)

No we use the system font to display the UI. The font you mentioned are used only in the score (and score like UI element like palettes, score preview etc...)

Can't we change to use e.g. FreeSerif instead?
Anyway, I've tested now: it works on my Windows XP pro too.
Found a typo though, fix on its way

Status (old) active patch (ready to commit)

And another problem: either lupdate or transifex doesn't deal with those \uXXXX strings from the CPP files, in transifex they end up as \XXXX.

Status (old) fixed active

The issue with the missing \ in \uXXXX is still remaining.
No idea how to fix it.

I see these options:
use ♭ and ♯ directly in CPP files
use b and # in CPP files, and translate them to ♭ and ♯ on Transifex
find out where the \ gets lost and fix it

use ♭ (♭) and ♯ (♯) in CPP files does not work unfortunately, here the & gets lost, resp. interpreted as staring a shortcut or shown as plain text

*find out where the \ gets lost and fix it
Is the \ in the file produced by lupdate?

* I have no problem using b and # in the cpp code... they are more urgent matter...

* using ♭ and ♯ directly in CPP files is not an option

No idea about the lupdate, I can't get a 'make lupdate' to work here.
As per a quick search on the Qt forum, the syntax \uXXXX should work, so my suspicion is that Transifex loses them?

I'm afraid so... (and thanks for checking)
Are you doing it or should I prepare and send a PR?
The change back is only needed in limbscore/keysig.cpp and mscore/importmidi_opmodel.cpp, the other CPP files are fine, as there these strings are not (yet?) translatable.

Status (old) patch (ready to commit) fixed

PR had been merged a while ago.
Today I fixed the remaining ones from CPP files via the translations, for en_US and a couple days ago for en_UK