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:
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.
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…
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
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
I don’t really know about this, but could be something worth looking after for…
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:
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).
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.
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).
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?
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.