← Back to team overview

kicad-developers team mailing list archive

Re: OS X Help Search Path patch

 

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

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

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.

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.

Adam Wolf
Cofounder and Engineer
W&L

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

> I agree with Bernhard here.  Putting this at the same level as the
> kicad.app bundle presumes that everyone will install the entire Kicad
> directory from the dmg.  I, for one, simply install the kicad.app bundle
> directly in /Applications.
>
> All the work that Bernhard did was aimed, I thought, at making it possible
> to migrate from the old way of installing a directory full of application
> bundles, to a drag and drop install of a single app-bundle.  The
> sub-applications in the Kicad directory are symlinks and are entirely
> optional.  For those that chose to launch them from the kicad launcher, the
> kicad.app bundle is entirely standalone and relocatable.  Making it rely on
> something being next to it changes that, even if it isn’t essential for the
> application to run.
>
> I’ll second Bernhard’s suggestion that they should go into the application
> bundle or, if their size is prohibitive, into a known location that is
> already used for support files such as /Library/Application Support.
>
>
> Garth
>
>
> > On Nov 17, 2014, at 10:55 PM, Bernhard Stegmaier <
> stegmaier@xxxxxxxxxxxxx> wrote:
> >
> > Hi again,
> >
> > I forgot…
> >
> > If you want to put it into the bundle (what I really would vote for, see
> end of the mail), then you can use
> >  GetOSXKicadDataDir()
> > defined in common/common.cpp to get the path to the SharedSupport folder
> inside of the main bundle.
> >
> > Also, I would propose to correctly wrap all OSses in correct #ifdefs and
> only define one path (at least for OS X).
> > That’s how I did with the previous patches changing paths.
> >
> > It basically doesn’t hurt to have more than one path defined, but IMHO
> this only creates confusion, because in the end you have many possibilities
> but you don’t know where it is intended to be. And, this is something a
> normal user shouldn’t see/change at all, so there is no need to have
> choices.
> >
> > Regarding the links you mentioned in your previous mail:
> > The links are just helpers for those who directly want to run pcbnew et.
> al.
> > If you throw them all away you are still able to do everything by means
> of the kicad launcher.
> > The same is true if you move kicad.app to another place… old links won’t
> work any longer, you might have to create new ones, but everything will
> always work via the kicad launcher.
> > This won’t be true if you don’t put the help files *inside* the
> kicad.app bundle… if you move kicad.app around, help files won’t work any
> longer.
> > As I understood OSX the concept of an application is the bundle, not a
> folder, dmg or something else.
> > Everything needed for the app to run self-contained has to be inside the
> bundle...
> >
> >
> > Regards,
> > Bernhard
> >
> > On 18.11.2014, at 07:35, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>
> wrote:
> >
> >> Hi,
> >>
> >> since help files is something directly used/delivered with KiCad
> (nothing that a user can/will change), shouldn’t this directly go into the
> bundle.
> >> E.g., kicad.app/Contents/SharedSupport/help?
> >>
> >> If you put on the same level as kicad.app, you can’t move kicad.app
> around as you like I guess (without moving also help files around).
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >> On 18.11.2014, at 06:54, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> I have set up a patch for adding an additional search path for help
> files for OS X.
> >>>
> >>> It searches inside a help/ directory at the same level as the
> kicad.app/ bundle, along side eeschema.app and all the other .apps.
> >>>
> >>> I have tested this on my OS X 10.10 system.
> >>>
> >>> Please let me know if you have any feedback on the patch.  I am fine
> wrapping it all in an OSX ifdef, but it looks like the Windows and Linux
> ones are not (and were, historically, but that part is commented out?)
> >>>
> >>> I tried to match the existing code in the file as much as I could.
> >>>
> >>> Thanks!
> >>>
> >>> Adam Wolf
> >>> Cofounder and Engineer,
> >>> W&L
> >>> <mac-helpfiles.patch>_______________________________________________
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References