Hi Marco, I'm glad you agree that .pkg is not a good option. How do you suggest we get data into /Library/Application\ Support/kicad? Should we have users drag a folder into there?
Adam Wolf Wayne and Layne, LLC On Mon, Mar 17, 2014 at 10:03 AM, Marco Serantoni <marco.serant...@gmail.com > wrote: > Adam, > 1) is the approach we will have dmg/zip file. > 2) there was a package manager, but becomes an hell to configure put in > bzr that forced us to remove few years ago. > 3) Requires 1), applications are downloaded from a bundle. > > Jean-Paul, /opt is something that should be used for command line > applications, not for GUI ones, try to interact with that will lead you in > different behaviour of Finder between versions. > Command line binaries related to Kicad should be placed in the bundle, > like happens for Xcode with the compiler/SDKs. > > The > /Library/Application Support/kicad is the path where the executables > expect to find their data. > > Wayne is a common error, OSX is POSIX and have the BSD API but is not BSD > in its organization. > OSX has a mach kernel (not a BSD one) in which there is the BSD subsystem, > like in the past NT had a POSIX subsystem. > Like each distro have completelly different approach in package manager > and organization for configuration files. > I've already tried to explain why, that neither the pure wxStandardPaths > before the K-way will work. > > > > -- > Marco > > > On Mon, Mar 17, 2014 at 2:11 PM, Adam Wolf > <adamw...@feelslikeburning.com>wrote: > >> I think that'll work for users who want to compile their own. From a >> packaging and distribution standpoint: I'm excited for kiways. >> Distributed Mac applications come in 3 types: >> >> 1) a DMG that contains a .app bundle that you drag to /Applications. >> This is basically what installing to /Applications does, except minus the >> packaging step (which I already scripted) >> 2) a .pkg installer. These can install files all over your system, but >> then uninstalling means running the .pkg again. Users don't like these as >> much as #1. >> 3) from the Mac App Store. (Probably not a short term solution for us >> right now--hopefully someday!) >> >> If we can set it up so that everything is contained in the .app, then we >> can do #1 for distribution. What's stopping us now from doing that is that >> multiple .apps want to refer to the same libraries, so we have to have a >> place outside of the .app that is common. Once we have kiways, this should >> be doable, right? >> >> Other Mac folks, what do you think? (Other non-Mac folks too...) >> >> Adam Wolf >> Wayne and Layne, LLC >> >> >> On Mon, Mar 17, 2014 at 12:22 AM, Jean-Paul Louis <lou...@yahoo.com>wrote: >> >>> Wayne, >>> >>> Thank you for your detailed reply. >>> I will add -DCMAKE_INSTALL_PREFIX=/Applications/Kicad/ to my script, >>> and the library files in /Library/Application Support/Kicad/ from my >>> clone of github. >>> >>> I do not understand why we need two different repositories (bazaar for >>> the software, and github for the data), but I can live with that. >>> >>> Anyway, every component used in my designs is always copied to a custom >>> library that store only the components that I use. >>> That way, I do not worry about anything related to my design being >>> overwritten by an update, and I do not have to browse through hundred of >>> files to find what I need. >>> >>> I will try this on my next build after renaming my current Kicad to >>> kicad_old, >>> and will post my results. >>> >>> Jean-Paul >>> >>> >>> On Mar 16, 2014, at 7:14 PM, Wayne Stambaugh <stambau...@verizon.net> >>> wrote: >>> >>> > On 3/14/2014 9:17 PM, Jean-Paul Louis wrote: >>> >> Wayne, >>> >> >>> >> OS X is a strange beast. >>> >> Apps are installed in more than one place. >>> >> /usr/local/ is not visible from the finder, but /opt/local/ is. >>> >> When I got a package prebuilt, it was installed in >>> /Applications/KiCad/, which was fine. >>> > >>> > It sounds to me like the default install location for OSX installers is >>> > /Applications. I'm not sure why CMake is not using that as the default >>> > install prefix. It uses the correct paths on Windows and Linux. >>> >> >>> >> When I build from source with minimum interaction (cake, make, make >>> install), >>> >> /demos and /templates ends-up in /usr/local/share/kicad/. >>> > >>> > You can always override CMake's default install path by using >>> > -DCMAKE_INSTALL_PREFIX=install_path to get KiCad installed where you >>> > want it installed. >>> > >>> >> >>> >> kicad is in several places >>> >> >>> >> Jean-Pauls-MacBook-Pro:kicad jean-paullouis$ sudo find / -name kicad >>> >> Password: >>> >> /Applications/KiCad/kicad.app/Contents/MacOS/kicad >>> >> ... >>> >> /usr/local/bin/kicad.app/Contents/MacOS/kicad >>> >> /usr/local/lib/kicad >>> >> /usr/local/share/doc/kicad >>> >> /usr/local/share/kicad >>> >> >>> >> I am trying to find a way to have all the *.app under the >>> /Applications/KiCad/, >>> >> and all the data under the home directory, so I can update/upgrade >>> without touching the data. >>> >> ~/Documents/ would be acceptable, I would prefer ~/Data/. >>> >> Github is OK for storage, but local storage is better for >>> efficiency/load. >>> > >>> > I would not put the component or footprint libraries in your ~/ folder. >>> > This will remove the temptation of modifying them only to have them >>> > overwritten the next time you update them. It's best to create new >>> > libraries and leave the default libraries unchanged. >>> > >>> >> >>> >> What is the best route to do just that? >>> > >>> > You should be able use git to create your own branch form >>> > https://github.com/KiCad/kicad-library. The CMake installer file is >>> > still there so you can run cmake -DCMAKE_INSTALL_PREFIX=path_to_intall >>> > and then make install. I'm guessing you will have to have admin >>> > privileges to install them in the system paths so the sudo command >>> > should work. If you choose this option, you will have to periodically >>> > pull the changes from github to keep your libraries up to date. >>> > >>> > Wayne >>> > >>> >> >>> >> Regards, >>> >> Jean-Paul (AC9GH) >>> >> >>> >> >>> >> >>> >> On Mar 14, 2014, at 7:08 PM, Wayne Stambaugh <stambau...@verizon.net> >>> wrote: >>> >> >>> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote: >>> >>>> >>> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh <stambau...@verizon.net> >>> wrote: >>> >>>>>> >>> >>>>>> The idea of keeping Kicad libs in Github is great, but if the >>> >>>>>> first-time-ever user has to set it up in some system config files >>> or run >>> >>>>>> bash scripts (think of Windows users!), it will ruin his >>> experience >>> >>>>>> (sorry for sounding Steve Jobs-ish...). Eagle, DesignSpark and >>> Altium >>> >>>>>> have libraries working out-of-the box. Why we shouldn't? >>> >>>>>> >>> >>>>>> My proposal is add a configuration window (see attachment) that >>> appears >>> >>>>>> the first time freshly installed Kicad is launched. What do you >>> think of >>> >>>>>> this approach? >>> >>>>> >>> >>>>> Hey Tom, >>> >>>>> >>> >>>>> Yes I agree that it should just work and it should. The problem >>> is not >>> >>>>> in the code AFAICT. The problem appears to be in the location >>> where the >>> >>>>> default fp_lib_table file is installed on OSX. When either CvPcb >>> or >>> >>>>> Pcbnew are run for the first time without a define fp_lib_table >>> file in >>> >>>>> the user's platform dependent home folder, an attempt is made to >>> copy >>> >>>>> the default fp_lib_table file to the user's home folder. On Linux >>> the >>> >>>>> default fp_lib_table file is stored in /usr/share/kicad/template >>> and >>> >>>>> copied to ~/. If the default file cannot be found, then there is >>> no >>> >>>>> choice but to create an empty fp_lib_table file which is what >>> appears to >>> >>>>> be happening on OSX. The path(s) searched for the default >>> fp_lib_table >>> >>>>> are defined in EDA_APP::FindLibraryPath(). If the path that the >>> OSX >>> >>>>> installer is placing the default fp_lib_table is not in the list of >>> >>>>> paths, then that is the problem or there is potentially a file >>> >>>>> permission problem preventing the file from being copied. This >>> used to >>> >>>>> work fine on both Windows and Linux so if no one changed it, it >>> should >>> >>>>> still work. >>> >>>> >>> >>>> >>> >>>> >>> >>>> Wayne the problem is not the code and this is CLEAR. >>> >>>> The problem is that there isn't an installer to install programs >>> under OSX, that can be placed by the user anywhere under /Applications >>> directory. >>> >>>> The other issue is that the /Applications directory is not supposed >>> to guest "support files", so the combination of the two things doesn't >>> allow me to hardcode it on FindLibraryPath. >>> >>>> I've also tried to think an arrangement on that, but interacting >>> with Dick on ticket #1267911, i've understood with error that EDA_APP is >>> gone, letting me wait Kiway. >>> >>>> </code> >>> >>> >>> >>> Where do the KiCad template files get installed on OSX when you >>> install >>> >>> KiCad using the OSX bundle? That is where the the path should point >>> to >>> >>> when attempting to copy the default fp_lib_table file to the users >>> home >>> >>> folder. I would prefer not use EDA_APP::FindLibraryPath() but rather >>> >>> wxStandardPaths::GetDataDir() with the appropriate subfolders added >>> so >>> >>> this works out to be: >>> >>> >>> >>> Windows: path_to_kicad_binary/../share/templates >>> >>> Linux: prefix/share/kicad/templates >>> >>> OSX: kicad.app/Contents/SharedSupport/templates >>> >>> >>> >>> This is valid for windows and linux. Is this not valid for OSX or >>> are >>> >>> you saying that you cannot copy a file from the application install >>> >>> folder to the user's home folder? I really am confused because I >>> >>> thought OSX was essentially BSD which should be posix compliant. >>> >>> >>> >>>> >>> >>>> <user_interaction> >>> >>>> The limit of the previous approach is that the developer/packager >>> choose for the user if use the old libraries or the GitHub approach, not >>> letting the user choose what is better for him. >>> >>>> Probably the "startup configuration window/wizard" could be a mayor >>> enhancement for the user and solve also the other issue in a single move. >>> >>>> This was also the spirit that I had when the 31/12/2013 on the ML >>> i've asked a button to "fill in" the table starting from the old legacy >>> library path. >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Marco >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Mailing list: https://launchpad.net/~kicad-developers >>> >>> Post to : kicad-developers@lists.launchpad.net >>> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> >>> More help : https://help.launchpad.net/ListHelp >>> >> >>> >> >>> > >>> > >>> > >>> > _______________________________________________ >>> > Mailing list: https://launchpad.net/~kicad-developers >>> > Post to : kicad-developers@lists.launchpad.net >>> > Unsubscribe : https://launchpad.net/~kicad-developers >>> > More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
