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 <[email protected]> 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 <[email protected]> wrote: > >> 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 > > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
