AppImage version of MuseScore does not respect system font setting (Ubuntu/xfce4 & Arch/Mate)
Ubuntu 14.04, xfce4
GIT commit: 888788a
Normally, if I set a system font using xfce4's "Appearance" app, this is used by MuseScore (and most other apps) to set text for menus, dialog boxes, and other GUI controls. This works fine in MuseScore in my self-builds from master (using Qt 5.4), and in the 2.0.3 builds I get from the PPA (using either Qt 5.3 or Qt 5.4), but not in the AppImage build (using Qt 5.5). When running the AppImage build, I get tiny menus, presumably some sort of default font size that might look reasonable on a standard 96 DPI dispay, but on my 166 DPI display, it is tiny. I normally have my default font set to 13 pt, which renders about like a 10 pt font, but what I am seeing looks more like about a 6 pt font.
Of course, one would like to think Ubuntu & xfce4 could come up with and agree on a better way of handling high DPI displays, but for now, this is what one has to do.
Note this is totally unrelated to the scaling we do within MuseScore for the score, palettes, and other things we draw ourselves. Everything looks fine in the AppImage version of MuseScore *except* the menus, dialogs, and other plain UI text (sub-window title bars like "Inspector"). This is the stuff we always got right before even without the fancy scaling we do now. Apparently AppImage is failing to pass on the system font info to Qt (?), except that somehow the "Subsurface" app manages to display menus and dialogs well even in the AppImage version.
Comments
Try setting the environment variable QT_STYLE_OVERRIDE to the value "GTK+" and then launching the AppImage. Should work for any AppImage, not just the special ones I made the other day. If it works I can make it permanent.
If it worked then please tell me the output of:
If it didn't work, here's a link to the special AppImages I made that allow you to override LD_LIBRARY_PATH, and to pass in an option --no-lib-path to stop LD_LIBRARY_PATH from being added to inside the AppImage:
https://bintray.com/shoogle/test/MuseScoreDev-appimage-use-system-font-…
The newer one doesn't have a qt.conf file which gives a bit more flexibility in loading Qt plugins, which you can do by specifying QT_PLUGIN_PATH.
I'd be interested to hear opinions about whether users should be allowed to override LD_LIBRARY_PATH for the official AppImages. At the moment, the order in which directories is checked is:
But I could make LD_LIBRARY_PATH get checked first (as it is in the special AppImages). That increases user flexibility, but it means that users might accidentally override the AppImage libraries with their own.
@shoogle, I can report that on my ArchLinux x86-64 machine running Mate Desktop, I can reproduce the undesired behavior that marc describes...changing my system font does not respond.
I can also report that if I run "QT_STYLE_OVERRIDE=GTK+ ./MuseScoreNightly-201603301024-master-86f1e70-x86_64.AppImage -F", then MuseScore starts up with the System Font size which I had set via my Mate Preferences. (However, changing my system font size while already running the appimage will not immediately reflect changes in the appimage...only gets changes on start of appimage. But that should be good enough fix!)
Although on my LXDE ArchLinuxARM machine, the musescore appimage doesn't respect system font when use QT_STYLE_OVERRIDE=GTK+ while the non-appimage musescore (along with every other program including qtcreator) will respect the system font. So maybe that trick won't work for LXDE (although...maybe I should try that on a more non-fringe distro like Lubuntu).
OK, sorry for the delay.
Setting LD_LIBRARY_PATH to use Qt 5.4 with the special AppImage failed to load - a missing symbol _ZN7QString14trimmed_helperERS_. Adding "--no-lib-path" to the command line did not help.
Setting QT_STYLE_OVERRIDE=GTK+ worked as expected, which is great I assume. Yes, changes to system font require a restart to take effect, but that's true for the regular versions of MsueScore as well (eg, PPA, self-build).
echo $XDE_CURRENT_DESKTOP reports XFCE.
I have no opinion on whether users should be allowed to override LD_LIBRARY_PATH. Normally I guess one expects to, but I suppose it partially defeats the purpsoe of an AppImage?
my opinion on LD_LIBRARY_PATH is that the AppImage lib dir should be checked first. One of the advantages of AppImage is ability to hopefully produce reproducable behavior across the whole variety of linuxes, since everyone will using the exact same libraries. So when people report a buggy behavior on their AppImage, then we can more easily verify that the bug is due to musescore, and not quirky thing with a distro's libraries.
That was my initial thought, but LD_LIBRARY_PATH is not set by default. It will only be set on developers' machines, who will know what they are doing, hopefully... Alternatively, I could create an APPIMAGE_LIBRARY_PATH variable that would be checked before the AppImage libraries, and have LD_LIBRARY_PATH checked afterwards. I'll create a discussion on AppImageKit to see what probono thinks.
PR: https://github.com/musescore/MuseScore/pull/2513
LD_LIBRARY_PATH discussion: https://github.com/probonopd/AppImageKit/issues/126
Fixed in branch master, commit 2a62996fd9
Improve AppImages including fix #104106 use system font settings
Fixed in branch 2.0.3, commit bb8c9ff600
Improve AppImages including fix #104106 use system font settings
Automatically closed -- issue fixed for 2 weeks with no activity.
I still have the problem: The symbols in the pallets and in the menus are very small and I have to scale to 250% to see the score in a normal way.
I am on:
Linux debian 4.1.0-trunk-686-pae #1 SMP Debian 4.1.2-1~exp1 (2015-07-17) i686 GNU/Linux
I am using the actual download of the AppImage.
I have tried "QT_STYLE_OVERRIDE=GTK+" without success.
Any other hints?
This is a different problem. The system font *is* being honored - trying changing it then restarting MuseScore and you'll see.
The problem you are seeing is unrelated - MuseScore in some unusual situations can fail to correctly dectect the monitor resolution. We've seen this happen for people who have multiple monitors connected, and in one case, someone who has a television connected via an HDMI connection.
See #106241: Monitor resolution detected incorrectly, making sizes wrong for more information, and please comment there giving information about your system - specifically regarding your monitor size, resolution, and how it is connected.