This doesn’t seems to work. I’ve tried to compile this branch with a wrapper like yours:
But it makes no difference…Am I doing it right?
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.
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).
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!
1 Like
Yes, it works. Thanks!
1 Like
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.
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.
I think that I’m doing something wrong, because I’m not seeing the result of the echo cd…this is the code:
I’ve promoted the snap to the candidate channel:
sudo snap install musescore --channel=candidate
Thanks for creating this snap!
I use it under Ubuntu, and wanted to export to MP3 format. This requires the installation of the lame libraries, since they are missing from the snap – but I’m not sure how to do this properly (in a “controlled manner” apart from hacking them into the snap somehow.
I have the libraries installed “locally” (they work with the non-snap 2.0.3 version), which is obviously not enough. I can see that other snaps (like VLC) comes with the library installed locally to the snap.
1 Like
Hey @pnoman thanks for testing and thanks for the feedback!
A new version with the LAME library included is in the candidate channel: Could you refresh it and try again?
Thanks @pachulo! The release candidate seems to fix the problem, and I can now export to MP3 (as hoped for) 
The snap has been promoted to the stable channel:
sudo snap install musescore
Hope you enjoy it!
1 Like
When opening a file in MuseScore, I can navigate down through my home directory to find files but when I try and navigate through the snap directory, all I see is the musescore subdirectory.
I have MusicXML files generated from another snappy application under the snap directory which I would like to import into MuseScore.
It would seem that MuseScore doesn’t see the other application in the snap directory.
Is there a solution to this or is there a recommended way of importing files produced from other strict confinement snaps.
Any advice would be appreciated.
Snaps intentionally are not allowed to access each other’s data by default. The way to share data between snaps is typically via the content interface: The content interface. Alternatively, if musecore and your snap both plugs the home interface, your snap could put/export its data to somewhere in /home, then the musecore could look for the file there.
1 Like
Thanks for your good work! All credits to you obviously https://twitter.com/untriangle/status/925308589388042241
Would it be possible to change the Developer Website link from support at musecsore dot com to https://musescore.org/en/support ?
Thanks!
Snaps intentionally are not allowed to access each other’s data by default. The way to share data between snaps is typically via the content interface: The content interface1. Alternatively, if musecore and your snap both plugs the home interface, your snap could put/export its data to somewhere in /home, then the musecore could look for the file there.
Thanks for this answer. I was not intending to use the home interface as I understand this requires manual approval for my snap. Instead, I have created a desktop shortcut which runs a shell script which uses rsync commands to copy my output files to a directory in home. I am able to distribute this with my snap and users can copy the desktop shortcut to ~/.local/share/applications.
I’ve changed the Contact link! Thanks!
Thanks a lot! The snap is now also listed on the MuseScore download page https://musescore.org/en/download
1 Like