[SOLVED] Menus open then close immediately
Hi !
I'm on MuseScore 4.1, Ubuntu 23.04.
When I open a menu like "format-style", "format-page settings" or "measure settings", the window opens and closes instantly. On the other hand, I can go to "Edit-preferences". I already restored to the factory settings but it does not help.
Any idea ? Thanks for your help.
[SOLVED] I just found a solution after having the same problem with another application, which made me looks for it towards my system rather than MuseScore. I just changed the driver for my graphics card. Solved in 5 seconds... I should have thought about it before. A big thank you for your help anyway !
Comments
Are you using the AppImage downloaded from this site, or an unsupported third-party build? It's working fine for me on Debian. Could also be an issue with your graphics device/driver. Also, X11 or Wayland?
In reply to Are you using the AppImage… by Marc Sabatella
This is the AppImage downloaded from the site, yes. I use Wayland and you're true, this could be an issue with the device/driver but...what ?
Thanks for your help ;-)
In reply to This is the AppImage… by [DELETED] 5740731
If you're running Wayland, you may need to set up your environment variables to make sure MuseScore and other Qt apps are aware this. Try "QT_QPA_PLATFORM=wayland".
In reply to If you're running Wayland,… by Marc Sabatella
Ok. I didn't know what you were speaking about so I made a research and tried like this but the app does not launch.
gher@multivac:~/AppImages$ export QT_QPA_PLATFORM=wayland
gher@multivac:~/AppImages$ ./MuseScore-4.1.0.231921359-x86_64.AppImage
/lib/x86_64-linux-gnu/libjack.so.0
/lib/x86_64-linux-gnu/libnss3.so
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QSocketNotifier: Can only be used with threads started with QThread
20:20:37.276 | INFO | main_thread | GlobalModule | onPreInit: log path: /home/gher/.local/share/MuseScore/MuseScore4/logs/MuseScore_230725_202037.log
20:20:37.276 | INFO | main_thread | GlobalModule | onPreInit: === Started MuseScore 4.1.0, build number 231921359 ===
20:20:37.284 | ERROR | main_thread | LanguagesService | setCurrentLanguage: Error loading translator "/tmp/.mount_MuseScTZfCL5/share/mscore4portable-4.1//locale/qt_fr.qm"
20:20:37.292 | WARN | main_thread | IpcSocket | connect: failed connect to server
20:20:37.292 | WARN | main_thread | IpcSocket | connect: failed connect to server
20:20:37.292 | INFO | main_thread | IpcSocket | connect: success connected to ipc server
20:20:37.292 | INFO | 140415443396288 | IpcServer | listen: id: "f8ed51677a304465bfcea7d2d5c21757"
/tmp/.mount_MuseScTZfCL5/bin/mscore4portable: symbol lookup error: /lib/x86_64-linux-gnu/libEGL_mesa.so.0: undefined symbol: wl_proxy_marshal_flags
Hi strathamer!
I got the same problem!
Still looking for a solution.
Do you got an Intel Graphics?
Greetings, Dan
In reply to Hi strathamer! I got the… by brassandwood
Hi Dan !
Yes, this model : NV167 / Intel® UHD Graphics 630 (CFL GT2)
I didn't have the problem the first time I launched the app but now it's everytime I start it...
I have the same problem (Manjaro Linux, MuseScore 4.1 using the official AppImage from musescore.org), see issue 18608. Seems like this was labelled “community project” some days ago. That seems to mean that it’s unlikely for the MuseScore team to fix it. I hope I misunderstood because I think it’s a more severe problem than other “community” issues on Linux like missing VST support or using the “wrong” file picker (GTK instead of KDE).
In reply to I have the same problem … by Malte_M
Mmh... ok, thanks for the help.
MuseScore 3 still work but I love the interface of the new version.
In reply to I have the same problem … by Malte_M
It's important to realize that a huge portion of the features and improvements and fixes in MsueScore over the years has been provided by the community. Especially for system-dependent problems like this that only affect a small number of devices and cannot be reproduced by anyone on the core team. So don't think of that as meaning, it's not going to happen or not considered important - more an acknowledgement that this is the sort fo thing that has always been best handled by the open-source communtiy.
In reply to It's important to realize… by Marc Sabatella
Thanks for the clarification! And sorry if this sounded like a complaint.
Maybe the numerous threads in this forum complaining about how “they” – the professional core dev team – “broke” MuseScore with v4 gave me a wrong impression of how much community is still involved in development here – although I should’ve known or at least guessed better, having contributed not to MuseScore yet but to LilyPond for a few years.
In fact, I’d like to contribute to MuseScore. I already forked and tried to compile it and am currently struggling to teach QtCreator/clang to look for includes at the correct location. I don’t know much about X11/Qt/… internals so probably these system-dependent things would not be the first to start with but maybe I’ll have a look at some other simple issues I reported in the last few days. Could you give me a hint how/where to connect with other devs best?
In reply to It's important to realize… by Marc Sabatella
I fully understand and am simply looking for a solution to my problem. I can only say "thanks" for MuseScore which I use every day with great pleasure. Version 4 looks great and I can stay on version 3 while waiting for a solution. But maybe we'll find out where it can come from :-)
In reply to I fully understand and am… by [DELETED] 5740731
I am not using wayland, so i cannot test this.
What if you start it with:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libwayland-client.so.0 ./MuseScore-4.0.0-x86_64.AppImage
In reply to I am not using wayland, so i… by graffesmusic
Hi graffesmusic.
I tried your command, the app starts but still the same problem...
Thanks for the help !
In reply to I have the same problem … by Malte_M
I also do think it is not a "community project"! It is an issue on multiple Linux distributions by multiple users. For me it looks like a bad written qt command somewhere. So, please reopen it as bug for the dev-team!
In reply to I also do think it is no a … by brassandwood
Here is a powerpoint with a short clip of how it looks in musescore. Sorry for the ppt, but there is no other option to send a video here.
In reply to Here is a powerpoint with a… by brassandwood
Best way to communicate a video to others is to post to YouTube or similar and then paste a link here or whether you wish to communicate it.
In reply to Best way to communicate a… by Marc Sabatella
Or to add some file format in the allowed list. Theses are only allowed:
jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp xml mxl msc mscz mscx mscz, mscx, docx musicxml ts mid midi ly zip eps patch svg ove drm mss cap gp3 gp4 gp5 gpx gp qml tg 7z bww capx mpal kar sgu scw gtp gt3 gt4.
In reply to Or to add some file format… by brassandwood
While of course that's technically possible, free support websites have to be careful about how much storage space they use. That's a big part of why formats that are likely to come with large file sizes of it aren't allowed. Since there are other sites like YouTube that have much larger budgets and able to provide unlimited free storage as well as a nice online player, it makes much more sense to let them do what they do best, and let us do what we do best :-)
In reply to I also do think it is no a … by brassandwood
I think you misunderstand what the term “community project” means here. It doesn’t mean it’s not a bug. It’s right there on GitHub along with all others. The community tag just means it’s an area where the community is encouraged to help out as they always have through the history of MuseScore - by contributing code to fix problems they encounter as hundreds of others have done over the years.
Not all problems occur in all systems and if one developer can’t reproduce a problem, they often call on others to help. That’s what is happening here. We need those developers in the community who are able to to reproduce the problem to help diagnose the problem and propose a fix, because those of us who cannot reproduce the problem are not in a position to do so. That’s how open source software works and it’s one of its great strengths.
In reply to I also do think it is no a … by brassandwood
Re: community projects, see...
https://musescore.org/en/node/349691
In reply to Re: community projects, see… by Jm6stringer
The least we can say is that those community projects are not very successful.
Any idea why?
In reply to The least we can say is that… by graffesmusic
It took the Dorico team - from the start with 7 full time developers - more than 4 years to build a more or less stable first release. Then it lasted almost two years before the playback engine understood articulations. Next members of the community - realising the potential - started making expression mappings and other relatively simple periferals. I hope that the MuseScore development team gradually succeeds in its huge task in such a way that the quality of its product convinces potential volunteer developers that they have a unique chance to contribute to composers worldwide.
In reply to The least we can say is that… by graffesmusic
You mean the ones announced only two months ago? It's way too early to make any such judgements. But for the record, the community has been stepping up with quite a few bug fixes and other improvements. It was a bit difficult during the the long run up to 4.0 because so much was changing so fast and the core team was needing to keep a tighter control on development. But things are pretty much back to normal now. Meanwhile, though, much has changed since MuseScore 3 about the build process, coding style, and internal architecture. So it's taking developers a while to be able to come back up to speed and tackle larger projects. The fact that we are "community" developers mean we do this in our spare time. But we've always managed in the past and I see no reason to suspect we won't continue to do so, each at our own pace as always.
Hi guys !
Sorry I didn't answer earlier, I was on vacation. It seems that the problem is still there with the brand new version (4.1.1). The first time I opened the app, it worked perfectly, then the style menus disappeared... I have the same problem when I right-click on a measure and select Properties...
Here a screencast to show you the problem : https://youtu.be/DvMPZdsSz8Q
Thans again
I have a similar problem, Ubuntu 22.04 and Wayland, on Dell XPS with Intel and NVidia (I could not detect any difference when switching graphic to on-demiand, nvidia or intel with prime-select).
Running the latest AppImage some dialogs close immediately.
Then I tried with
QT_QPA_PLATFORM=wayland:```
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway
...
/tmp/.mount_MuseSclWKqAH/bin/mscore4portable: symbol lookup error: /lib/x86_64-linux-gnu/libnvidia-egl-wayland.so.1: undefined symbol: wl_proxy_marshal_flags
...
Even running on intel graphics card I get this error.
I tried graffesmusic's recommendation, using
QT_QPA_PLATFORM=wayland LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libwayland-client.so.0.This works in principle, but the dialogs are off and placed wrong, so that it is not always possible to navigate to the submenus (see screenshots).
@strathamer, you solved it by changing the graphics driver? Which one did you use and which one do you use now?
In reply to I have a similar problem,… by paulwellnerbou
Personnaly, I had to try 4 or 5 different drivers before I found the one wich works (a metapak from nVidia)... Sorry, I cannot help more, I don't have many skills on this subject...
Had this exact same issue especially with accessing FX as well as what OP suffered from as well, in Debian Linux GNOME in Wayland.
Solved it by installing a different Desktop Environment, in this case KDE on XOrg.
GNOME on XOrg doesn't solve the issue but KDE on XOrg did.
Just adding this comment for future readers out there.