Call for testing: MuseScore v2.1.0

[pachulo]

Hey everyone.

MuseScore v2.1.0 snap is now in the beta channel for amd64 & i386 arch:

$ sudo snap install musescore --channel=beta

Some interfaces need to be connected manually:

$ sudo snap connect musescore:cups-control
$ sudo snap connect musescore:network-manager

But most of the application functionality works without them.

If you’re a user of the application or even if you just want to poke at it, I’d love some help putting it through its paces! Please let me know if you run into any issues.

[jdstrand]

Thanks for this! I’ve always wanted to try musescore and this gave me a reason.

On Ubuntu 17.04 classic distro it segfaulted after I used the wizard to create a new score (I created a grand staff with electric guitar in treble and bass in bass). I clicked on the first measure to try to add a note (I don’t know what I’m doing so was just exploring the interface) which turned the rest blue. I then right clicked for a popup dialog and dismissed it. I was moving the mouse around to see how to enter a note and it segfaulted (ie, it seemed to not be related to a specific click event, but I’m not sure). I did not connect cups-control and network-manager. Other than the expected network-manager denial, I did have:

dbus[6171]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/a11y/bus" interface="org.freedesktop.DBus.Properties" member="Get" mask="send" name="org.a11y.Bus" pid=7507 label="snap.musescore.mscore" peer_pid=6261 peer_label="unconfined"

(I’ll fix the unity7 interface for that one). I don’t think this is related because I ran musecore again and it didn’t crash. Maybe this has something to do with first launch?

Here is the trace: http://paste.ubuntu.com/24841529/

[pachulo]

Yeah, it could be related with a first launch error, because I’ve tried what you said (in Ubuntu 16.04 thought) and everything seems to work fine. I will let the devs to see if they know what could cause it.

[Ads20000]

Works great (well, aside from one niggle below)! I’m not exactly sure how @jdstrand put different instruments on the different clefs of the grand staff but OK. What an aweeeesome snap though, thanks so much! Maybe worth passing to upstream unless they don’t want it (after more testing, obviously)?

It really irritates me that by default when you open a dialogue to open/save in a snap app, it often opens a directory inside the snap folder (happens with LibreOffice too). This is not very user-friendly!

In the case of MuseScore, it opens ~/snap/musescore/1/Documents/MuseScore2/Scores. So if someone saves here, presumably when the snap is updated their scores would then save in the revision 2 folder and they’ll wonder where all their scores have gone.

Maybe there’s some environment variable that can be set to change the folder that is opened when a open/save dialogue is first used, or maybe it’s hardcoded into MuseScore, I don’t know. Maybe should just open ~.

Here’s a little composition I made whilst to testing this snap, you probably won’t appreciate it unless if you’ve heard of a lad called Arnold Schoenberg…

[popey]

@Ads20000

In the case of MuseScore, it opens ~/snap/musescore/1/Documents/MuseScore2/Scores. So if someone saves here, presumably when the snap is updated their scores would then save in the revision 2 folder and they’ll wonder where all their scores have gone.

Actually that’s not what should happen. When the snap gets updated, the docs will be copied from ~/snap/musescore/1/Documents/MuseScore2/Scores to ~/snap/musescore/2/Documents/MuseScore2/Scores. When the user opens a file in the application, the new default should be ~/snap/musescore/2/Documents/MuseScore2/Scores

[pachulo]

@Ads20000

Maybe worth passing to upstream unless they don’t want it (after more testing, obviously)?

Upstream is already aware and they even created the musescore developer namespace in the store, but they granted me access to upload the builds for this snap.
The idea is that, when this is more tested, to be promoted to the stable channel and have 2.2 in the beta: https://github.com/musescore/MuseScore/pull/3204

@Ads20000

In the case of MuseScore, it opens ~/snap/musescore/1/Documents/MuseScore2/Scores. So if someone saves here, presumably when the snap is updated their scores would then save in the revision 2 folder and they’ll wonder where all their scores have gone.

Maybe there’s some environment variable that can be set to change the folder that is opened when a open/save dialogue is first used, or maybe it’s hardcoded into MuseScore, I don’t know. Maybe should just open ~.

I don’t really know about this, but could be something worth looking after for…

[jdstrand]

Several snaps use SNAP_USER_COMMON (~/snap/<snap name>/common) instead of SNAP_USER_DATA (~/snap/<snap name>/<version>) for this type of thing. I suspect (but don’t know) that if you cd into the user’s $HOME (as opposed to the snap’s $HOME), then it might work. To try this out, instead of calling ‘mscore’, you could create a small wrapper in /snap/musecore/current/bin that does something along the lines of:

#!/bin/sh
real_home=$(getent passwd "$(id -u)" | cut -d ':' -f 6)
cd "$real_home" && mscore "$@"

Then point desktop-launch at this file.

[gertim]

[pachulo]

Hey @gertim!
Regarding issue 1, this is normal, the snap can only access to your /home directory. In order to access that directory the snap should be classic mode, because I think that right now there is no interface to access /tmp: https://snapcraft.io/docs/reference/interfaces
Am I right @jdstrand?

Regarding 2…I haven’t tried, but maybe giving it access to the alsa interface will be enough…I will try to compile another version and let you know so you can try!

Thanks for the feedback!

[pachulo]

@jdstrand

To try this out, instead of calling ‘mscore’, you could create a small wrapper in /snap/musecore/current/bin that does something along the lines of:

#!/bin/sh
real_home=$(getent passwd “$(id -u)” | cut -d ‘:’ -f 6)
cd “$real_home” && mscore “$@”

Then point desktop-launch at this file.

OK, I will try to add it! Thanks!

[jdstrand]

@pachulo

Regarding issue 1, this is normal, the snap can only access to your /home directory. In order to access that directory the snap should be classic mode, because I think that right now there is no interface to access /tmp: https://snapcraft.io/docs/reference/interfaces

Actually, on a technical level the security policy does allow access to /tmp. The problem is that there is a per-snap /tmp directory and so the /tmp in the snap is not /tmp on the host. This cannot be fixed in the interfaces code. I’m not sure what is putting the score in /tmp, but it should be adjusted to put it in the user’s home instead (or the user can simply choose to download the score to ~/Downloads, or similar).

[pachulo]

@jdstrand

Several snaps use SNAP_USER_COMMON (~/snap/<snap name>/common) instead of SNAP_USER_DATA (~/snap/<snap name>/<version>) for this type of thing. I suspect (but don’t know) that if you cd into the user’s $HOME (as opposed to the snap’s $HOME), then it might work. To try this out, instead of calling ‘mscore’, you could create a small wrapper in /snap/musecore/current/bin that does something along the lines of:

#!/bin/sh
real_home=$(getent passwd “$(id -u)” | cut -d ‘:’ -f 6)
cd “$real_home” && mscore “$@”

Then point desktop-launch at this file.

This doesn’t seems to work. I’ve tried to compile this branch with a wrapper like yours:

• https://github.com/pachulo/musescore-snap/tree/wrapper-test

But it makes no difference…Am I doing it right?

[gertim]

Hi @pachulo,

About issue 1: Maybe I have to explain a bit more. I understood that testing was required to test with the normal expected functionality of MS, to get it ready for an update through the repository… So, I compared it with the normal functionality. Normally, I can, when I am on the website of MS, download a score or right away open it. The latter option is not working and that is where this issue refers to. I did not realize or understand anything (yet) about ‘snap’, I just installed it, like on top of this page and thought it would be comparable with normal functionality. Otherwise I don’t know what is normal for ‘snap’ or normal MS functionality. I probably have to get into what snap is and what it does and mean to go any further then, I guess.
ad 2. Thanks. I can’t wait to see and try it. You know, a main thing that I am doing this has to do with the fact that the app image of 2.1 doesn’t work with extra keyboard signs link ö, ä, ï etc. The standard keyboard combinations don’t work. So, every time one wants to enter such a combination, one has to use the extra input panel to add that as a symbol. That gives major delays in entering lyrics. So, I was looking for the normal install of 2.1 and I got this link through the mail from MS support. So, I am willing to test to get this working asap, if that’s the goal.

[jdstrand]

@pachulo

But it makes no difference…Am I doing it right?

You could add a comment to musecore.sh to make sure it is doing the cd. Eg:

real_home=$(getent passwd "$(id -u)" | cut -d ':' -f 6)
echo "cd $real_home"

Assuming when running your snap you see that debug message, you’d have to look in your snap or musecore code to see if it is doing a chdir() that overrides yours (or just more carefully inspect how it is setting up the path for the file dialog and adjusting that).

[pachulo]

Well, the new version is uploaded, a:

$ sudo snap refresh

Should get you the one with the ALSA interface declared.

Please note that you still have to manually connect the interface with:

$ sudo snap connect musescore:alsa

Let’s see if this is enough!

[gertim]

Yes, it works. Thanks!

[Ads20000]

@jdstrand

I’m not sure what is putting the score in /tmp

Firefox puts the score in /tmp if you say you want to open the file in MuseScore immediately. This is a serious usability issue. If we decided that the snap was so good (with automatic silent background updates and proper updates thanks to bundled dependencies) that we made it even less confusing for users to install by removing the Deb from the repositories (or at least hiding it from Ubuntu Software) and then having upstream recommend only the snap (or Flatpak, or AppImage) for Ubuntu users, those users will be completely confused when opening a score from Firefox and expecting identical functionality to the Deb - because opening the score won’t work. Is there nothing we can do (other than changing to classic confinement which should be avoided if possible because of manual reviews and because it would be nice to keep this sort of thing working on a theoretical all-snap Ubuntu) to keep this functionality?

[jdstrand]

The user should be in control of where the file is placed and putting it in /tmp by default is probably not the best idea anyway because if you download and open a score, you probably want to keep it and /tmp isn’t meant for persistent storage. If the way musescore works is if you want to keep it then you must ‘Save As’ (or something), then that should still work fine-- you save it to home somewhere.

Why is firefox defaulting to putting it there? Firefox has a way to configure this (about:preferences, then under the General tab). Two things seem to influence this: setting the directory and setting to always ask where to put the file (see https://askubuntu.com/questions/816983/firefox-browser-ubuntu-converting-all-my-downloads-to-tmp-files). Perhaps the musescore site is written in a way that it makes the files look like temporary files instead of regular downloads (I don’t the site or how to influence firefox in this regard…).

As for the general situation of sharing files via /tmp-- this is not supported at this time for the reasons I mentioned before because /tmp is something different to the snap and to the system’s firefox. It is technically possible to make using the per-snap /tmp optional, but I’m not sure this fits into the project’s plans. At a minimum, it would be confusing that some apps could see the system /tmp and others could not. An architect would have to weigh in on this.

[jdstrand]

@jdstrand

If the way musescore works is if you want to keep it then you must ‘Save As’ (or something), then that should still work fine-- you save it to home somewhere.

Actually this is wrong, the problem is that musescore can’t get to the file firefox downloaded in the first place. Other points still stand.

[pachulo]

I think that I’m doing something wrong, because I’m not seeing the result of the echo cd…this is the code:

• https://github.com/pachulo/musescore-snap/tree/wrapper-test