kicad-developers team mailing list archive

[Jean-Paul Louis <louijp@xxxxxxxxx>]

Hi Adam and Marco,

I agree with both of you. Let’s keep it simple.
A DMG bundle that have a “Kicad” folder with all the apps to be dragged into /Applications/.
Data Bundle in “Kicad” folder to be dragged into /Library/Application Support/.

We could have a small app which move everything to the right locations.

my $0.02,

Jean-Paul

On Mar 17, 2014, at 11:14 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:

> 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.serantoni@xxxxxxxxx> 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 <adamwolf@xxxxxxxxxxxxxxxxxxxx> 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 <louijp@xxxxxxxxx> 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 <stambaughw@xxxxxxxxxxx> 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 <stambaughw@xxxxxxxxxxx> wrote:
> >>
> >>> On 3/14/2014 5:32 PM, Marco Serantoni wrote:
> >>>>
> >>>> On 14/mar/2014, at 20:00, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
>

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail