Bug 1930759
| Summary: | Dialog box for updating old scores unusable | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Éric Brunet <eric.brunet> | ||||||||||
| Component: | mscore | Assignee: | Jerry James <loganjerry> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 33 | CC: | audrey, igor.raits, loganjerry, oget.fedora, pampelmuse | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| 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: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2021-03-29 00:16:15 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 1758173 [details]
The output of the mscore command
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. 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. 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. 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... 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. 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. Created attachment 1758916 [details]
The output of MuseScore-3.6.2.548021370-x86_64.AppImage
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. 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. 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. 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? 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 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/ Created attachment 1759214 [details]
The output of 02016950-mscore
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". 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 ? 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. 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. > 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. FEDORA-2021-ecd507d48d has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ecd507d48d FEDORA-2021-b9022a5468 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-b9022a5468 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. 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. 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. 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. 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. |
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.