kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

I guess one way to alleviate most of my concerns is to put the English help
inside the bundle, add a search path for both where I put it now, and
inside the bundle, and put the inside the bundle help at lower priority.

No matter where you move just kicad.app, help will work (even though none
of the other launchers will), users can add localized help which will take
priority, and it isn't a space hog.

I'll set that up this afternoon.

Adam Wolf
On Nov 18, 2014 7: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."
>
> 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
>>
>>
>