Bug 1930759 - Dialog box for updating old scores unusable
Summary: Dialog box for updating old scores unusable
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mscore
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jerry James
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-19 14:12 UTC by Éric Brunet
Modified: 2021-04-02 01:21 UTC (History)
5 users (show)

Fixed In Version: mscore-3.6.2-3.fc34 mscore-3.6.2-3.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-29 00:16:15 UTC
Type: Bug


Attachments (Terms of Use)
The dialog box (167.08 KB, image/jpeg)
2021-02-19 14:12 UTC, Éric Brunet
no flags Details
The output of the mscore command (25.63 KB, text/plain)
2021-02-19 14:15 UTC, Éric Brunet
no flags Details
The output of MuseScore-3.6.2.548021370-x86_64.AppImage (2.87 KB, text/plain)
2021-02-23 20:05 UTC, Éric Brunet
no flags Details
The output of 02016950-mscore (4.75 KB, text/plain)
2021-02-25 08:52 UTC, Éric Brunet
no flags Details

Description Éric Brunet 2021-02-19 14:12:14 UTC
Created attachment 1758172 [details]
The dialog box

I have an uptodate fedora 34 laptop with kde. I am reporting a bug against mscore-3.6.2-1.fc33.x86_64, but the bug was already present in the mscore 3.6.1 package.

When opening a score written with mscore 3.5.*, mscore 3.6.* opens a dialog box asking whether the score should be updated to the new mscore style. That dialog box is unusable:
*) the text facing the checkboxes is unreadable
*) the button "Apply New Style", which is originally greyed out (since there is nothing yet to apply), disappears when one of the checkbox is selected, instead of becoming ungreyed and clickable.

This is perfectly reproducible. I don't know how to apply the new style.

I haven't seen any problem with other dialog boxes.

Comment 1 Éric Brunet 2021-02-19 14:15:22 UTC
Created attachment 1758173 [details]
The output of the mscore command

Comment 2 Jerry James 2021-02-19 18:12:09 UTC
Hmmm, I've used that dialog box several times and it worked just fine for me.  But I'm running GNOME on an X session.  You're running KDE on Wayland, perhaps?

If you start MuseScore from a terminal, like this:

mscore -R

does the dialog box appear normal?  That starts without loading any of your settings.  There have been weird bugs in the past that turned out to stem from settings files written by an older version of MuseScore.

Comment 3 Audrey Yeena Toskin 2021-02-19 21:48:49 UTC
Seems even worse on Rawhide (f35) with GNOME/Wayland -- even with all-default settings, when opening a v3.5 document, MuseScore completely locks up just before the conversion dialog would even appear.

But the issues goes way, the MuseScore 3.5 document loads and can convert without error, with running GNOME in an Xorg session.

Comment 4 Éric Brunet 2021-02-19 22:06:05 UTC
Thanks for looking at this.

The problem is still present with mscore -R  .

I am not running wayland/kde, but good old Xorg with kde.

I tried to remove some of the unusual options I might have been using; and I think I found the culprit: I have a Hidpi display, and Xorg is run with the "-dpi 192" option:

% tail -3 /etc/sddm.conf
[X11]
EnableHIDPI=true
ServerArguments=-nolisten tcp -dpi 192

If I remove the "-dpi 192", I can hardly read anything, but musescore's dialog box looks ok.

Comment 5 Audrey Yeena Toskin 2021-02-19 22:33:43 UTC
Could you scale your display from the KDE Plasma settings instead of adding a command line switch to X?

In GNOME Shell, it's GNOME Tweaks > Fonts > Scaling Factor. It's been a while since I used Plasma, but I assume there's a similar "display scaling" or "font scaling" setting...

Comment 6 Éric Brunet 2021-02-20 08:49:30 UTC
Display scaling in plasma is not in a very good shape. There is a global Scaling factor, which can be configured, and I can play with font sizes, but I find it is not satisfactory and I need to set dpi as well. Maybe I am missing an easy solution, but right now I need this -dpi thing.

Moreover, I'd argue it is beside the point. Even if there were another, easier way to scale my display, I think very strongly that musescore (or any program) should work even if a slightly non-standard option as been selected. Setting the dpi for the X server has been possible for ages!

Now, it might be that the issue lies with Qt. I don't know. But I only have a problem with that dialog for that program, so I would guess the bug is in the way the dialog is coded.

Comment 7 Audrey Yeena Toskin 2021-02-23 19:49:55 UTC
Last thing to test might be to download the official AppImage.

  https://musescore.org/en/download/musescore-x86_64.AppImage

Download that file, add execution permission, and run it. If you have the same issue with the dialog, then that would prove it's a bug in the application itself, rather than this package.


> I think very strongly that musescore (or any program) should work even if a slightly non-standard [Xorg DPI] option as been selected...

Right, clearly there's a bug somewhere that should be fixed. I just meant scaling from the Plasma settings as a workaround unless or until that happens.

Another possible workaround, from the MuseScore GitHub issues: MuseScore might be detecting the display resolution incorrectly...

  https://github.com/musescore/MuseScore/issues/7440

So you override the DPI with the `-D | --monitor-resolution DPI` command line argument.

Comment 8 Éric Brunet 2021-02-23 20:05:17 UTC
Created attachment 1758916 [details]
The output of MuseScore-3.6.2.548021370-x86_64.AppImage

Comment 9 Éric Brunet 2021-02-23 20:14:34 UTC
Thanks for your suggestion.

I don't see the bug with the AppImage executable, it seems to work very nicely.

I see (from the Help menu) that the AppImage executable is linked against Qt 5.9.8, while the dynmaic Qt library in my distrib is Qt 5.15.2. It seems like a big difference.

The AppImage executable has much fewer warnings than the executable from my distrib. I had already attached the output of the latter, I have now attached the output of the former so you can see the difference.

I also tried the -D command line argument on my distrib's executable. This has an effect on button sizes, but not on font sizes, and it doesn't help with the issue at hand.

Comment 10 Jerry James 2021-02-25 00:28:18 UTC
That dialog's source files are in mscore/qml/migration.  Alas, I am unfamiliar with qml, but maybe somebody reading this bug can take a look in that directory to see if there are any possible connections to the reported symptoms.

Comment 11 Jerry James 2021-02-25 00:38:15 UTC
Although now that I look at the mscore output you attached, this jumps out at me:

qrc:/qml/migration/ScoreMigrationDialog.qml:156: TypeError: Cannot read property 'button' of null
qrc:/qml/migration/ScoreMigrationDialog.qml:133: TypeError: Cannot read property 'buttonText' of null
qrc:/qml/migration/ScoreMigrationDialog.qml:131: TypeError: Cannot read property 'font' of null

... and many others that are similar.  This means that "globalStyle" is null.  I do see the other warnings in your attachment on my system, but not those.  I think we need to figure out how globalStyle is supposed to be set to something non-null, and why that isn't happening for you.

Comment 12 Jerry James 2021-02-25 02:55:40 UTC
It looks like globalStyle should be set from the "Theme" dropdown in Preferences.  Mine is set to "Light".  What is yours set to when MuseScore is misbehaving?

Comment 13 Audrey Yeena Toskin 2021-02-25 04:00:41 UTC
Getting extra eyes on this issue at the MuseScore support forum could also help. I'm a little out of my depth here, so I dunno how well I could explain the problem, but if one of you wanted to repost over there...

https://musescore.org/en/forum/6

Comment 14 Jerry James 2021-02-25 05:01:50 UTC
I think that's a good idea, as I'm feeling out of my depth as well.  I did, however, find this, which talks about issues with Qt 5.15.x:

https://github.com/musescore/MuseScore/pull/7388

Here's a build with that patch applied:

https://copr.fedorainfracloud.org/coprs/jjames/MuseScore/build/2016950/

Comment 15 Éric Brunet 2021-02-25 08:52:54 UTC
Created attachment 1759214 [details]
The output of 02016950-mscore

Comment 16 Éric Brunet 2021-02-25 09:25:00 UTC
Thank you for all the comments and suggestions.

My Theme is also set to "Light", I didn't see any weird thing in the Preferences menu.

I have downloaded and installed build 2016950. This new build of mscore yields much fewer warning (see new attachment), but unfortunately my bug is still present.

I have posted a message on https://musescore.org/en/forum/6 . My message is "queued for moderation".

Comment 17 Éric Brunet 2021-03-21 10:25:24 UTC
Hi. This bug (about the dialog box for updating scores to musescore 3.6.x) is still present on my computer, which is expected (nothing really changed).

Yesterday, I upgraded both of my sons' computers to the latest fedora 33, which carries musescore 3.6.2. As their computers are not HiDpi, and as there are no unusual -dpi settings or any plasma scaling, I thought they would not be affected by this bug.

Well, one of them is affected by the bug, and the other is not. I really don't know what provokes this, but it is more complicated than a a problem with the -dpi option to the X server.
(What annoys me is that my son who is affected by the bug really uses musescore a lot, and it is a problem for him... For the moment, I replaced fedora's musescore by the official AppImage, but it is not ideal.)

Also, it looks like the message I posted on https://musescore.org/en/forum/6 did not pass moderation: it never appeared, I never got an email back. Should I post another message ?

Comment 18 Éric Brunet 2021-03-21 15:13:44 UTC
I have been trying to understand what is going on, and I found a reliable way to suppress the bug on my computer. I just need to unset three environment variables: XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, DESKTOP_SESSION.

(
Specifically, I invoke mscore from the command line with 

XDG_CURRENT_DESKTOP= KDE_FULL_SESSION= DESKTOP_SESSION= mscore

and it works.
)

Normally, these variables have the following values:

XDG_CURRENT_DESKTOP=KDE
KDE_FULL_SESSION=true
DESKTOP_SESSION=/usr/share/xsessions/plasma

So, it looks like when musescore detects it is running under kde, it does something differently and the bug happens.

There are too many environment variables nowadays. I have no idea what they are for, and when they are set and by what.

Comment 19 Éric Brunet 2021-03-21 19:29:38 UTC
Digging a bit more, here is what I understand. When one of these variables is set, Qt detects it runs under kde, and it loads the /usr/lib64/qt5/plugins/platformthemes/KDEPlasmaPlatformTheme.so library from the plasma-integration packages. (I check that point stracing mscore with and without the environment variables.) Then it tries to conform to kde style, and anything can happen because the end result will depend on dozens of configuration settings in kde. I don't even understand how it could be possible, but the bug seems to disappear if I choose a dark color theme instead of a light one!

It is not the first time such an issue occured; running some searches, I found the following similar bug (now fixed?): https://bugs.kde.org/show_bug.cgi?id=425949

I would like to add to the CC list the people overseeing bugs in Qt and in kde, but I don't know how to do that.

Comment 20 Audrey Yeena Toskin 2021-03-23 23:00:46 UTC
> Also, it looks like the message I posted [...] did not pass moderation

That's annoying. But...


> XDG_CURRENT_DESKTOP= KDE_FULL_SESSION= DESKTOP_SESSION= mscore ...and it works

Éric, seems like you're getting close enough to an actual bug report that you could try taking it directly to the developers. So maybe resend to the MuseScore repository on GitHub, rather than their support forum...

I suspect that the MuseScore devs will say it's a bug in Qt. But I imagine they'll have an easier time narrowing down the possible buggy Qt components than the Qt devs would have figuring out an issue with a MuseScore component, if it were the other way around.


Jerry, in the meanwhile, maybe we should patch the .desktop file? Éric's command line, launching mscore with those "DESKTOP" variables cleared, does not seem to create any regressions for me on GNOME, and if it helps it work more reliably for KDE users, then seems probably worth doing. Since the bug is situational, I don't suppose we're getting a fix from upstream right away.

I'll send a pull request on src.fedoraproject.org so that you can review before merging, since you'd been working on this package for longer than I have.

Comment 21 Fedora Update System 2021-03-24 15:10:49 UTC
FEDORA-2021-ecd507d48d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ecd507d48d

Comment 22 Fedora Update System 2021-03-24 15:10:49 UTC
FEDORA-2021-b9022a5468 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9022a5468

Comment 23 Éric Brunet 2021-03-24 18:20:04 UTC
Hi,

thanks for all the activity. I have made a bug report on the musescore webpage, at https://musescore.org/en/node/319187 (On the github, I had the impression that all the bus were for Musescore 4.) Maybe at some point I'll need to make a bug report on the Qt bugsystem, and another one on the kde bugsystem...

Changing the .desktop file is a nice idea. It won't help dinosaurs like me who type the program name in a terminal, but that's .001% of the population, so it is not a problem.

If I may, I'd suggest using a different workaround:

QT_QUICK_CONTROLS_STYLE=Base mscore

If I understand correctly, this imposes a style for qt quick controls, and then qt does not try to emulate kde for these dialogs. The advantage is that the file selector (and probably other dialogs) still look like kde's file selector with this workaround, while it looks like the plain qt selector with the other workaround.

Comment 24 Fedora Update System 2021-03-25 01:24:14 UTC
FEDORA-2021-b9022a5468 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-b9022a5468`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9022a5468

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 25 Fedora Update System 2021-03-25 01:32:15 UTC
FEDORA-2021-ecd507d48d has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ecd507d48d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ecd507d48d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 26 Fedora Update System 2021-03-29 00:16:15 UTC
FEDORA-2021-b9022a5468 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 27 Fedora Update System 2021-04-02 01:21:00 UTC
FEDORA-2021-ecd507d48d has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.