MuseScore
MuseScore copied to clipboard
musescore
Options in the menu appear on the incorrect monitor
Issue type
UI bug (incorrect info or interface appearance)
Description with steps to reproduce
- Open Musescore 4.4 with two monitors
- Select any item on the top left menu (File, Edit, View, Add, etc)
Actual behaviour: The options appear on the incorrect monitor when on the main display Expected bahviour: The options appear on the correct monitor
Supporting files, videos and screenshots
https://github.com/user-attachments/assets/49dc6938-df37-41e1-8f38-ed6a324bc285
As I do not have screen recording software that records two monitors, I have recorded it on my phone. Apologies for the poor quality.
What is the latest version of MuseScore Studio where this issue is present?
4.4.0
Regression
Yes, this used to work in a previous version of MuseScore 4.x
Operating system
Windows 10
Additional context
Please note my display setup at the start of the video
Checklist
- [X] This report follows the guidelines for reporting bugs and issues
- [X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
- [X] I have attached all requested files and information to this report
- [X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible
In addition, dialogue boxes are also appearing on the wrong monitor too, and the splash screen on startup.
Same here, but I have three screens (which windows labels 3, 1, 2). Menus and dialogues always open on the leftmost screen (3), regardless of where the MS app is open. When MS is on the leftmost screen (3), everything appears in the correct place, but when its elsewhere, the UI items that appear on the leftmost screen (3) are as far right as they can go without showing anything on the middle screen (1).
Incidentally, the Appearance pop-over that appears when clicking the button in the Properties pane doesn't appear at all on any screen when the MS window isn't on my leftmost screen. Something very odd about multi-screen set-ups - are these tested in the release process?
Same problem.
I use two displays. Primary on the left, secondary on the right. The window always appears on the right when opening the program, even though that's the secondary display. If I move the window over to the primary display, the pulldown menus appear on the secondary display, as if that's where the main window is. I don't know about other dialogs, etc. I didn't test those, but I see others say they are messed up too.
Also, I see no way to have the program appear on the primary display when I open MuseScore. If I previously closed the program when the window was maximized, it always opens on the secondary display.
This is only if I use the window maximized. If not fully maximized, then the program seems to remember the position and size when opening. It remembers which display I was on too in that case. Either way, the menu positions are messed up.
It's almost as if the developer that tested this code has his primary display on the right, and secondary on the left. Just a guess.
I've used GitHub Windows build artefacts to try to see when this was introduced, but the 4.3.2 nightly builds all work, and 4.4.0 only goes back as far as mid-June, when this bug was still present, so it was introduced some time before then.
Using Windows 10 and MuseScore Studio v4.4.0.242390800. I use 3 monitors, with my main display on the right, second on the left, and then a third above.
When I have MuseScore Studio open on my main (right) monitor, and I click on a menu item, the dropdown options appear in my secondary (left) monitor.
For me, only the splashscreen and any old-style "QWindow" dialogs (e.g. measure properties) are appearing on the wrong monitor. 95% sure that was true even with MS 4.0. Windows 11.
Might be worth checking a version of 4.x built before Qt6 was introduced though? (13/2/2024)
These Qt forum posts don't make me very hopeful: https://forum.qt.io/topic/139419/tooltips-and-menus-on-wrong-screen https://forum.qt.io/topic/155514/combobox-popup-and-dialogs-on-the-wrong-screen saying it got fixed only with Qt 6.6!
The Qt issue tracker is a bit more confusing than that: https://bugreports.qt.io/browse/QTBUG-118695 indeed only fixed in 6.5.4 (private) or 6.6.1 https://bugreports.qt.io/browse/QTBUG-97533 was fixed in 6.2.5
The latter gives a little bit of hope that #24095 fixes it; that would be worth trying out.
@cbjeukendrup I just downloaded the Windows build artefact from #24095 and it fixes the issue for me.
That's good news! Well then I'll try if I can finish that PR for 4.4.3. The problem with it is that it causes some texts to randomly disappear on macOS. Alternatively we can of course use different Qt versions on different OSs for the time being. Not sure if that's desirable though.
Along with the problems as given in earlier comments, I just noticed that the "new score" dialog. which lets you set settings for key, time signature, tempo, and number of measures for a new score, only work if I have my whole MuseScore Studio window on my secondary display. If I have my main window on my primary display, the dialog shows okay on the primary display, but the buttons controlling those settings appear to do nothing. That's because the child dialogs to change those settings (when clicking on the main buttons) just don't get displayed, even on my other display. They are nowhere to be found.
All of this works fine if I keep everything on my secondary display. For me MuseScore has become almost unusable in its current state, because I am forced to use only my secondary display. But editing or doing any kind of work on that secondary display other than just viewing, is awkward at best, because that display is way off to the side.
Regrettably, the fix for this general problem with secondary displays appears to be low priority. It keeps getting pushed back to later and later updates, now slated for 4.4.3, two versions from the current 4.4.1. The bug was introduced in 4.4.0.
There are other bugs with "file-new", if you use it when a score is open the dialog doesn't show at all if you have another musescore instance with no score open. Should be fixed in latest nightly though, and not technically related to multiple monitors, though the behaviour can still be a bit surprising when you are using multiple monitors (it can be hard to predict which monitor the dialog will appear on).
It's certainly not low priority; the reason that it has been moved from 4.4.1 to 4.4.2 and now from 4.4.2 from 4.4.3 is that there is simply no solution found yet, but we don't want to delay other bug fixes just because of this. So we're already creating a release with the fixes that we do have, and at the same time continue to look for a solution for this issue.
It seems likely that this is a Qt bug indeed. We're currently using Qt 6.2.4, and there are reasons to update to 6.2.9, see https://github.com/musescore/MuseScore/pull/24095. Above, someone reported that this seems to fix it for them. But as also mentioned above, we can't just apply that update, because it causes problems on other OSs; even if we decide to apply this update on Windows only, that will require very thorough testing (you never know what will break, when updating Qt) and is almost too risky to do in a patch release of MuseScore. Anyway, if this issue is fixed by the Qt update, that alone seems enough reason to me to try hard to apply that update as soon as possible, i.e. 4.4.3.
I've asked the original reporter of that issue on .org (https://musescore.org/en/node/368201#comment-1257831), still awaiting a reply.
Same here big time on win11. This is a &#^$&# disaster, making it unusable with two monitors which is my standard workstation setup. regressed to an earlier version but now I can't edit any scores saved with the updated version, which although I have backups may not have my most recent edits (I believe a workaround is save to music xml and reload - painful). Showstopper bug needing immediate attention. I note that it's a QT thing which would also explain why my QT plugin no longer works in this version, another reason to retrograde my setup. Very unhappy that this didn't get regression tested (from a veteran software developer)
You can configure 4.3 to read 4.4 scores (you still get the "error" but it loads anyway).
It's certainly not low priority; the reason that it has been moved from 4.4.1 to 4.4.2 and now from 4.4.2 from 4.4.3 is that there is simply no solution found yet, but we don't want to delay other bug fixes just because of this. So we're already creating a release with the fixes that we do have, and at the same time continue to look for a solution for this issue.
It seems likely that this is a Qt bug indeed. We're currently using Qt 6.2.4, and there are reasons to update to 6.2.9, see #24095. Above, someone reported that this seems to fix it for them. But as also mentioned above, we can't just apply that update, because it causes problems on other OSs; even if we decide to apply this update on Windows only, that will require very thorough testing (you never know what will break, when updating Qt) and is almost too risky to do in a patch release of MuseScore. Anyway, if this issue is fixed by the Qt update, that alone seems enough reason to me to try hard to apply that update as soon as possible, i.e. 4.4.3.
Thanks @cbjeukendrup for your explanation. I had a feeling this was the problem. Having dabbled a bit with Qt in years past, I've never liked it. My main beef with it is that it adds yet another layer of types onto C++, making it almost its own language, and making things even more complex than it would be otherwise.
You can add me to the list of Qt anti-fans, though for me it's primarily having to use Qml with no type safety or decent debugging tools (my brief foray into trying to use QtCreator quickly reduced me to tears). But I doubt that's going to change any time soon, and it's not like there any ideal alternatives. Having to write native GUI code for Windows Mac and Linux in something as big as MuseScore would be pretty horrible. Curious how other notation software packages do it though.
The reason that this issue is in "needs porting" is that it needs porting to the master branch (rather than to 4.4.3). That will happen via the Qt 6.8 PR, where this issue is listed. Since that PR is in the 4.5 project, I think we can now safely move this issue to "Done" in the 4.4.3 project.
I'm getting this bug in 4.5.2
I'm on Windows 11, using 2 monitors set to different aspect ratios When I first launch it works fine, but if I move MuseScore between screens then the bug occurs, and persists until a restart
OS: Windows 11 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.5.2-251141402, revision: github-musescore-musescore-ac9d3bc
Could you please try if it does work correctly in the latest nightly build from https://musescore.org/en/nightly-builds?
It does not occur in the 4.6 nightly build. All seems to be working correctly Thank you MuseScore Studio version (64-bit): 4.6.0-252250324, revision: github-musescore-musescore-07350f4