… then I’ll also have to resend … :) Hi Adam,
I somehow share your dislike of packages, because there is no uninstall… especially when it comes to Samsung printer drivers (however, other are not better)… :) I also like the dmg version of apps much more. You’re right, 75% sounds much for now… is this already a scripting build? My last scripting build was much larger than 30M if I remember correctly. And if you start to add libraries, the ratio also will get better… :) Sounds good… let’s start this way and see if maybe some other nice idea wrt to installing language-specific help files comes up somewhere down the road. Regards, Bernhard On 18.11.2014, at 20:25, Adam Wolf <[email protected]> wrote: > 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
