Whoops, accidentally sent to only Bernhard. Resending to list. (Btw Bernhard, I added a line at the end...)
Hi Bernhard, Thanks for the reply. I'm definitely not going to stop the Jenkins stuff--I just have no interest in maintaining a .pkg, because I think it is a worse user experience. When I think of packages, I think of things that can't clean up after themselves, or crap released by companies that don't know what they're doing Samsung printer drivers. I definitely trust them much less than something I install with a DMG. I agree that not everyone agrees with me--but this is my reasoning for not wanting to make a pkg. I don't think users like them, and I definitely don't like them, so I don't really want to spent hours a week making them better. :) I made a bunch of pkgs when I was a full time Linux/Mac sysadmin--you're right, they're no harder to create. Right now the KiCad DMG is 30 megs. I'm willing to concede and include all of the help files inside, but please note that over 75% of the package size will be help files. It certainly does matter on the Jenkins server, but I can throw money at that problem. So, here's my proposal. I include all the help inside the bundle, tripling the size of the packages. I set up a DMG with two drag targets. The first is Kicad/ which contains Kicad.app and the rest of the .apps, and the drag target is /Applications. The second is kicad/ and the drag target is ~/Library/Application Support/. Inside of kicad/ is libraries, templates, and some config files (I think). If the second target doesn't work, we may have to have three directories that you drag to ~/Library/Application Support/kicad/. I think we can make that clear with a background image on the dmg. How does that sound? Adam Wolf Cofounder and Engineer, W&L On Tue, Nov 18, 2014 at 1:12 PM, Adam Wolf <[email protected]> wrote: > Hi Bernhard, > > Thanks for the reply. I'm definitely not going to stop the Jenkins > stuff--I just have no interest in maintaining a .pkg, because I think it is > a worse user experience. > > When I think of packages, I think of things that can't clean up after > themselves, or crap released by companies that don't know what they're > doing Samsung printer drivers. I definitely trust them much less than > something I install with a DMG. > > I agree that not everyone agrees with me--but this is my reasoning for not > wanting to make a pkg. I don't think users like them, and I definitely > don't like them, so I don't really want to spent hours a week making them > better. :) > > I made a bunch of pkgs when I was a full time Linux/Mac sysadmin--you're > right, they're no harder to create. > > Right now the KiCad DMG is 30 megs. I'm willing to concede and include > all of the help files inside, but please note that over 75% of the package > size will be help files. It certainly does matter on the Jenkins server, > but I can throw money at that problem. > > So, here's my proposal. I include all the help inside the bundle, > tripling the size of the packages. > > I set up a DMG with two drag targets. The first is Kicad/ which contains > Kicad.app and the rest of the .apps, and the drag target is /Applications. > The second is kicad/ and the drag target is ~/Library/Application > Support/. Inside of kicad/ is libraries, templates, and some config files > (I think). > > How does that sound? > > Adam Wolf > > On Tue, Nov 18, 2014, 12:45 PM Bernhard Stegmaier <[email protected]> > wrote: > >> 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
