kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Garth,

Sure.  I still don't like it, but I don't have any more time to discuss
this.

If this ends up mutating into a package installer, I will step back and let
someone else handle Mac builds.  I have absolutely no interest in that.

The help path doesn't look at /Library/Application Support.

Adam Wolf
Cofounder and Engineer
W&L

On Tue, Nov 18, 2014 at 10:19 AM, Garth Corral <gcorral@xxxxxxxxx> wrote:

> Comments inline
>
> > On Nov 18, 2014, at 5:15 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
> wrote:
> >
> > Well, folks, I guess I can put them inside of kicad.app, but I'm not
> really sold on it.
> >
> > 0) To reiterate, I'm suggesting including the help in the dmg, but not
> inside the kicad.app.  The installation process would remain like it is
> today.
> >
> > 1) You already cannot move kicad.app around without moving
> bitmap2component.app, cvpcb.app, eeschema.app, gerbview.app,
> pcb_calculator.app, pcbnew.app, and pl_editor.app or they stop working, so
> I do not think that "you can't just move kicad.app anymore" is valid.
> Also, help doesn't work today, and I didn't even see a bug filed for that,
> so it might be important to distinguish "the help shortcut in the menu bar
> wouldn't work" with "kicad doesn't work."
> >
> Those things at the same level as kicad.app are (or at least should be)
> symlinks.  They’re meant as a convenience for folks that want to run them
> without launching kicad.app, but they’re not needed. The actual application
> bundles are inside the kicad.app bundle.  If you move kicad.app yes, those
> symlinks stop pointing to the right thing but kicad.app and all associated
> sub-applications will continue to work just fine.  You’d just have to
> create new symlinks (or aliases which don’t care if the main bundle is
> moved).
>
> Bernhard and I discussed some various alternatives to symlinks, but
> ultimately symlinks were the simplest.  I was in favor of not including
> them at all as they just add confusion, but others rightly pointed out that
> there are those who still prefer to invoke them separately.  For those that
> don’t, though, simply dragging kicad.app into /Applications (without the
> sub-application symlinks) works just fine.
>
> > 2) I don't think it is uncommon to put help files outside of a
> bundle--then users can delete it easily if they want.  I do not want to say
> "If you want to save space, go inside the bundle and delete the PDFs."
> >
> It’s not uncommon to put things outside the bundle, but you’re proposing
> making a relative path from inside the bundle to outside the bundle, and
> thus imposing an installation structure on people.  It is far less common
> to drag a directory full of support files into the /Applications directory
> than to simply drag a bundle in there.  That’s what most people expect, and
> that’s the intent; /Applications wasn’t meant as a place for application
> support files, there’s already a place for that, /Library/Application
> Support.  If you do wan’t them inside the bundle, that’s accounted for in
> the SharedSupport directory as Bernhard suggested.
>
>
> https://developer.apple.com/library/ios/documentation/CoreFoundation/Conceptual/CFBundles/AboutBundles/AboutBundles.html
>
>
> > 3) While it might make sense to put one set of PDFs inside the bundle, I
> want to have a supplementary dmg of "all the help files for all the
> languages".  If I put the help outside of the bundle, I can expect a
> typical Mac user to change the contents of the help/ directory next to
> kicad.app, but I do not want to write instructions explaining how to put
> the help files inside of the bundle.
> >
> As I said, if you’d prefer them not to be there then I suggest a location
> that is already for this purpose, such as /Library/Application
> Support/kicad.   Please don’t put them in the /Applications directory
> outside the bundle.
>
>
> > 4) This is a search path, not "the only place to put them".  I can
> certainly add a search path inside the bundle and outside the bundle for
> anyone else who wants to store their help inside the bundle, but at this
> point, I think there's a lot of value to keeping help outside the bundle.
> >
> Don’t a lot of the other search paths already look in /Library/Application
> Support?
>
>
> > Adam Wolf
> > Cofounder and Engineer
> > W&L
>
>
> Garth