The patch following adds support for Mup, a music publication program. It transforms a raw text input file into PostScript music score. Two file extensions are used here: 1. *.mup: I have checked filext.com, .mup is unofficially taken by another program which also does music publication, but the program is for Windows only, so there is not much conflict here. Mup is for Unix platforms (you can check out http://arkkra.com/) 2. *.not: Another GUI music notation program, noteedit, also uses the same file format but save the content with another file extension.
Created attachment 1893 [details] [review] Patch supporting mup file format.
Probably only Christophe will take care of bug reports, trying to reassign.
Abel, I'm getting all mails about bugs assigned to jrb, so I got notified of this one as well ;) I didn't commit the patch since the file format needs pretty specialized, so I need to make a decision about that ;)
Actually, I'm creating a syntax highlight (in gtksourceview) for this syntax. Without MIME type, I can do nothing to make it recognize the file format (because it's just plain text), and have to abandon. The counterpart for KDE has already been in CVS (done by somebody else), and the last missing piece of puzzle is a proper MIME type. All the needed work has already been done. Talking about specialness, it is probably a bit more used then you think, because AFAIK quite some people like to create simple melodies for themselves -- it's a reason why rosegarden (another graphical music editor/synthesizer) is so popular. However, if it is still decided this format is not good enough for general consumption, please take a look at #335. The chemistry formats listed there was already standardized, and used in all chemistry software, be it open source or not. The bug has been sitting there long enough.
> Without MIME type, I can do nothing to make it recognize the file format (because it's just plain text), and have to abandon. Not necessarily, mime types don't need to be in the shared-mime-info database to get installed, any app can install its own mime types. If you tell me defining these mime types in gtksourceview doens't make much sense, I agree with you however ;) And yeah, I know about the chemical mime types, but this is mainly the same problem as these, I don't know much about this field, so I don't know how widespread those files are, what produce them, ...
> any app can install its own mime types. If you tell me defining these mime types in gtksourceview doens't make much sense, I agree with you however ;) Hm, the problem of this approach is, this format is used by 2 programs, not only 1. If this info is not appropriate for shared-mime-info, where should it be put into? As a side note, here are the 2 programs that can handle this format: 1. Mup (http://www.arkkra.com/) 2. Noteedit (http://noteedit.berlios.de)
Christophe: If there is no common 3rd party distributor for the MIME spec, we'll probably have to include it. Abel: Any news?
"spec" should have been "info".
Status is still the same: nobody is distributing this MIME type, and also unlikely in the future. Although it is absurd for me to think a decision is made based on developer's familiarity with particular MIME type (in this case most existing MIME type should not have been included), I'm not objecting to any decision made. This type is indeed quite specialized.
Thanks, I've committed a patch with a slightly modified description.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.