kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Can we do everything that a normal user needs in two locations, or do we
need three?

For instance, the applications end up in /Applications or
/Applications/kicad.  The help files and libraries and modules and
templates and KiCad config files end up in *a* Library/Application\
Support/kicad.  Should they, by default, for normal users, go to /Library,
or ~/Library?

If they all go into one location, I should be able to create a single kicad
directory with all of those support files that people drag into a symlink
to the appropriate Application Support.  Does this create merging
difficulties?  Do we need to have a help and library and module and
template directory that people drag into the symlink one-by-one?  Do we
need to have people drag help and library and module and template into
/Library/Application Support/kicad, and configs into ~/Library/Application\
Support/kicad?

I personally think that dragging two things in a dmg is about the limit
before the dmg gets silly.

Bernhard?  Garth?

Adam Wolf

On Tue, Nov 18, 2014 at 10:32 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
wrote:

> 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
>
>
>