kicad-developers team mailing list archive

[Marco Serantoni <marco.serantoni@xxxxxxxxx>]

Obliusly a second .dmg with only libraries to avoid confusion and adding
the possibility for the user to be archived if needed.

--
Marco


On Mon, Mar 17, 2014 at 6:01 PM, Marco Serantoni
<marco.serantoni@xxxxxxxxx>wrote:

> Jean-Paul,
> I don't agree with "Programs".
> Until now OSX has supported /Library/Application Support/kicad and
> $HOME/Library/Application Support/kicad
> (Order: Own Home before, then system one)
> To be failsafe we could arrange a .dmg with a Symbolic Link and the Arrow
> "Copy here", is a well know approach for OSX users, here some links with
> examples:
>
> http://jhelioviewer.org/imgs/JHelioviewer_OSX_installer_screenshot.png
> http://www.visitusers.org/images/1/10/VisItMac_dmg.png
>
> http://ruby.bastardsbook.com/assets/images/fundamentals/installation/run-code-step-by-step/mac-textwrangler-dmg.png
>
> The issue in this case will be the $HOME/Library[..] link that we could
> ignore for the moment.
> This simplification could be not sufficient for a machine that is used
> from multiple users.
>
> pkg is not a "not like", just we got issues in the past with it that a
> simpler approach could avoid.
>
> --
> Marco
>
>
> On Mon, Mar 17, 2014 at 4:47 PM, Jean-Paul Louis <louijp@xxxxxxxxx> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>>
>