Comments inline > On Nov 18, 2014, at 5:15 AM, Adam Wolf <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
