Re: MacOS release help

[Jean Abou Samra]

Le 18/10/2022 à 08:12, Alex Harker a écrit :
> > On 18 Oct 2022, at 00:05, Carl Sorensen <carl.d.sorensen@gmail.com> 
> > wrote:
> >
> > IMO, what we most want is an app bundle that can be easily relocated 
> > anywhere and that provides all of the binaries used by LilyPond.  
> > Frescobaldi can be pointed at that app bundle to run LilyPond.
> >
> > I recognize that most apps have a GUI.  But it's not strictly 
> > necessary to have a GUI in the app bundle, if I understand correctly.
>
> I can’t be certain on whether the GUI is strictly necessary, because 
> I’ve never considered the alternative, but an app bundle with no GUI 
> is not something I’ve ever seen on MacOS, so I would not advise making 
> one.
>
> However, the notion of a MacOS package on Mac is more general than an 
> app bundle, and is simply a folder that has some metadata. The 
> contents of the folder can be whatever you want, whereas an app bundle 
> implies other things (like it will launch when double clicked and I 
> think the bundle structure is expected to follow a given pattern). If 
> what is required is just a single ’thing’ (as far as most users are 
> concerned) then a package (but not a app) might be most appropriate. 
> They can be used for anything where a bunch of structured resources 
> should be kept together (some apps use them for documents, for 
> instance, such as Logic Pro X - which allows it to keep a bunch of 
> audio files inside something that looks like a ‘file').
>
> The downside of the package approach would be usage entirely on the 
> command line, although the barrier may be too small to be considered 
> relevant. In the terminal packages act just folders and you can cd 
> into them. In the finder you can also look inside them, but need to 
> explicitly open them with a right-click contextual menu selection to 
> ’Show Package Contents’. Most end users are unaware of this and see 
> packages as if they were opaque files. I also don’t know how a package 
> approach would operate if someone wanted to install to usr/local or 
> similar in order to be able to run lilypond binaries without having to 
> type the full location - I can take a look at that.



I am starting to think that since Frescobaldi is the most complete
and beginner-friendly LilyPond environment out there, having a good
installing experience for Frescobaldi and LilyPond together would make
the installing experience for LilyPond without Frescobaldi much less
relevant.

In particular,

- as I said earlier, it would be great to have a .dmg for Frescobaldi 3.2,

- Frescobaldi could gain an interface for easily installing various
  LilyPond versions, and the first launch of Frescobaldi could just
  open this interface.

  It seems that the old Frescobaldi 1 actually had this. It corresponds to
  https://github.com/frescobaldi/frescobaldi/issues/313


Jean