Oh boy, much to read… :) Be prepared, this will be a long reply. First, come on, Adam. You did an awesome job setting up the Jenkins and being willing to provide automated builds. Please don’t throw that away. It’s just a technical discussion…
=== Is OSX so different than Linux? === No, it isn’t. On Linux you have: (1) Binary folder => /usr/bin (2) Machine data (for all users) => /usr/share (3) User data => /home/<user> (4) User specific configs => /home/<user>/.config/... On OSX you have the same with different names: (1) /Applications (2) /Library/Application Support (3) /Users/<user> (4) /Users/<user>/Library/Application Support/… The only difference is that for (1) in Linux all the app mess is in one folder, whereas in OSX you have much cleaner for each application its own folder and OSX hides everything below it. For Linux, the rules where to put what are made by Debian et.al. and I guess no one would be happy if you create a /usr/help folder for KiCad help files. In Linux things would go to (2), just probably like thy could on OSX. In OSX you additionally can hide mandatory things a user shouldn’t fiddle around with by putting it into the bundle in (1). For me, help files are such things… I don’t see any benefit of having them separate. === Where should go what? === I think that is easy: (a) Everything that mandatory ships with KiCad and is not intended to be changed by users => (1) (b) Everything else common for all users of the machine => (2) (c) User specific stuff => (3)/(4) That’s exactly how search paths are configured at the moment (at least everything that I found and changed and still exists - as I learned pcbnew doesn’t use search paths at all), just the other way round (c) => (b) => (a). Normally, in a multi-user environment (a)/(b) will only be writeable by administrators… About libraries you could start another discussion… is this user or machine data? Well, in a company maybe it’s machine data which users can use but mustn’t change… you will however find as many reasons that it is user specific data. === Why I don’t like the help folder parallel to KiCad applications? === Well, it’s ugly and it imposes a installation structure that I must not break. Think of that: You create a start menu folder “KiCad" in Windows with all the nice icons for the binaries in it and the help folder directly in there (no link or something linke that, but physically located in the start menu folder). I am a naive user and I … * hate this, because the folder is ugly, I want to have a clean start menu, and I delete it ... * drag the KiCad icon to the desktop because I use it every minute… => help doesn’t work any longer… uh, what bad thing did I do? Where is the support forum? Or: Look at your iOS or Android tablet. You see many nice icons for apps in there… I don’t want to see folders for program data in there. === Do we need an installer? === If you want ultimate flexibility and best user experience, yes. In Linux its nice that almost every distribution has its installer (= package manager), so there is fortunately nothing to do on KiCad side. For OSX as well as Windows this is not true. If you want maximum flexibility you would have to create the usual installer with some nice check-boxes for maybe each language, libraries, 3d-models, templates, etc. and the installer would take care of putting everything into the right spot. Do we need it now? I guess no. First, help is IMHO mandatory for a professional package. I just checked and all pdf’s together are ~10MB. 10 languages? Overall 100MB. I don’t care… do you? If you want to “simulate” an installer by drag&drop from a dmg, then probably yes, you would have to provide one drag&drop path for every option. And I fully agree with you… too many drag&drop paths will confuse more than it helps. === So, my proposal for now === Keep things simple and be happy with the first automated and official OSX binaries. Put all existing help files into the bundle, so normal OSX user can’t break anything doing whatever is allowed on OSX with the main kicad.app bundle (move around, copy, etc.). Create a dmg with two drag&drop options… one for application, one for libraries. If things really start getting too big, someone may start thinking of how to create an installer. I quickly googled a bit and creating an installer with pkgutil doesn’t seem to be so hard, all the tools needed seem to be provided by Apple. I guess it will be about the same effort than correctly packaging KiCad for Debian or any other Linux distribution... Regards, Bernhard On 18.11.2014, at 17:44, Adam Wolf <[email protected]> wrote: > 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
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
