Re: [Kicad-developers] Local Variables
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
Re: [Kicad-developers] Local Variables
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.comwrote: 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.comwrote: 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
Re: [Kicad-developers] Local Variables
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.comwrote: 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.comwrote: 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
Re: [Kicad-developers] Local Variables
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 adamw...@feelslikeburning.com 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.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
Re: [Kicad-developers] Local Variables
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 lou...@yahoo.com 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 adamw...@feelslikeburning.com 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.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.comwrote: 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.
Re: [Kicad-developers] Local Variables
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.serant...@gmail.comwrote: 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 lou...@yahoo.com 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 adamw...@feelslikeburning.com 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.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.comwrote: 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
Re: [Kicad-developers] Local Variables
(I agree with Marco.) On Mon, Mar 17, 2014 at 12:01 PM, Marco Serantoni marco.serant...@gmail.com 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 lou...@yahoo.com 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 adamw...@feelslikeburning.com 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.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.comwrote: 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
Re: [Kicad-developers] Local Variables
If you wish, there are some old templates, look if you could do something with artworks at: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/files/head:/packaging/mac-osx/ There you can find my LD pkg maker (a pain), just ignore it. And an old Jerry Script to make .dmg, that could be a good startpoint, probably the artworks are reusable too. Please use a FULL shell scripting approach if is possibile, i feel better than native scripts and less problematic for all to manage and submit patches (other scripts are binary, i don't like it due the difficulties to make review). Also please be aware that some paths will need an adjustment. -- Marco On Mon, Mar 17, 2014 at 6:03 PM, Adam Wolf adamw...@feelslikeburning.comwrote: (I agree with Marco.) On Mon, Mar 17, 2014 at 12:01 PM, Marco Serantoni marco.serant...@gmail.com 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 lou...@yahoo.comwrote: 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 adamw...@feelslikeburning.com 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.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.comwrote: Wayne, Thank you for your detailed reply. I will add
Re: [Kicad-developers] Local Variables
On 3/17/2014 1:03 PM, Marco Serantoni wrote: Obliusly a second .dmg with only libraries to avoid confusion and adding the possibility for the user to be archived if needed. Can't this be rolled this into one installer? The CMake and Freecad dmg files seem to include all the necessary samples, libraries, and documentation files all in one dmg file. I also noticed that there are pre and post install scripts that could be used to set things like environment variables as well. The contents of dmg files look a lot like deb files in terms of capabilities. Maybe you can provide an installer with just the apps and the docs for folks who are going to use the github plugin and another installer that also includes all of the libraries. I think having separate installers for the apps and the libraries is going confuse users. Wayne -- Marco On Mon, Mar 17, 2014 at 6:01 PM, Marco Serantoni marco.serant...@gmail.com mailto:marco.serant...@gmail.com 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 lou...@yahoo.com mailto:lou...@yahoo.com 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 adamw...@feelslikeburning.com mailto:adamw...@feelslikeburning.com 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.serant...@gmail.com mailto: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 mailto: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
Re: [Kicad-developers] Local Variables
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:
Re: [Kicad-developers] Local Variables
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
Re: [Kicad-developers] Local Variables
Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. Is there someplace that Mac kiway is being discussed? Adam Wolf Wayne and Layne, LLC On Fri, Mar 14, 2014 at 9:14 AM, Dick Hollenbeck d...@softplc.com wrote: Marco, http://bazaar.launchpad.net/~kicad-stable-committers/kicad/kiway/view/head:/include/project.h#L169 This is a place to put variables, we could easily migrate variables from the environment into here, a project specific place, with the environment being a fall back search. I actually think it would be easiest to provide the editing from the wxPython top level GUI. This would be easier for users than setting variables in the environment, or so I'm told. And I don't see a reason why we can't put them in the *.pro file as part of this re-organization and introduction of class PROJECT. Dick ___ 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
Re: [Kicad-developers] Local Variables
On 03/14/2014 10:24 AM, Adam Wolf wrote: Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. That's a rather sad statement. Before the advent of the GUI (I know I am showing my age), even the secretary (before they were called personal assistants) at my first job knew how to set environment variables to get DOS to print to a specific printer without the assistance of tech support or the engineering department. Apparently now, folks who are technically competent enough to lay out a PCB cannot be bothered with learning how to set up their OS works so that they can configure it properly. I confess myself disappointed. :( Wayne Is there someplace that Mac kiway is being discussed? Adam Wolf Wayne and Layne, LLC On Fri, Mar 14, 2014 at 9:14 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: Marco, http://bazaar.launchpad.net/~kicad-stable-committers/kicad/kiway/view/head:/include/project.h#L169 This is a place to put variables, we could easily migrate variables from the environment into here, a project specific place, with the environment being a fall back search. I actually think it would be easiest to provide the editing from the wxPython top level GUI. This would be easier for users than setting variables in the environment, or so I'm told. And I don't see a reason why we can't put them in the *.pro file as part of this re-organization and introduction of class PROJECT. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto: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
Re: [Kicad-developers] Local Variables
I definitely can see what you're saying Wayne, and I have absolutely no problem setting them myself, but the actual feedback seemed to be completely reasonable: So now, outside of the project preferences and the program preferences, we have another place to set settings? (I do remember having my fair share of problems when multiple programs modified AUTOEXEC.BAT and CONFIG.SYS thinking they knew best...) Adam Wolf Wayne and Layne, LLC On Fri, Mar 14, 2014 at 9:33 AM, Wayne Stambaugh stambau...@verizon.netwrote: On 03/14/2014 10:24 AM, Adam Wolf wrote: Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. That's a rather sad statement. Before the advent of the GUI (I know I am showing my age), even the secretary (before they were called personal assistants) at my first job knew how to set environment variables to get DOS to print to a specific printer without the assistance of tech support or the engineering department. Apparently now, folks who are technically competent enough to lay out a PCB cannot be bothered with learning how to set up their OS works so that they can configure it properly. I confess myself disappointed. :( Wayne Is there someplace that Mac kiway is being discussed? Adam Wolf Wayne and Layne, LLC On Fri, Mar 14, 2014 at 9:14 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: Marco, http://bazaar.launchpad.net/~kicad-stable-committers/kicad/ kiway/view/head:/include/project.h#L169 This is a place to put variables, we could easily migrate variables from the environment into here, a project specific place, with the environment being a fall back search. I actually think it would be easiest to provide the editing from the wxPython top level GUI. This would be easier for users than setting variables in the environment, or so I'm told. And I don't see a reason why we can't put them in the *.pro file as part of this re-organization and introduction of class PROJECT. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto: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
Re: [Kicad-developers] Local Variables
On 03/14/2014 03:33 PM, Wayne Stambaugh wrote: On 03/14/2014 10:24 AM, Adam Wolf wrote: Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. That's a rather sad statement. Before the advent of the GUI (I know I am showing my age), even the secretary (...) Hi Wayne, In my humble opinion, it's not a matter of technical competence, but the first impression that Kicad makes on the first-time user. Most people expect software to work more or less out of the box, even the advanced ones (that's why among proprietary tools me my folks @ CERN prefer Altium over Cadence, despite the latter being much more powerful). When somebody buys a Mac, the usual reason is it to avoid having to edit config files. I know many extremely competent analog designers who simply use autotrax or old orcad, just because they didn't require any configuration. 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? Cheers, Tom attachment: sel_window.jpeg___ 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
Re: [Kicad-developers] Local Variables
Tomasz, This might be easier to do in the packaging step. There's already ways to check out local copies of the symbols and make them available (I forget the name of the script offhand, something local install.sh or something). In the package, we can certainly make that happen by default while still allowing people to configure as much as they want. Adam Wolf Wayne and Layne, LLC On Fri, Mar 14, 2014 at 10:11 AM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 03/14/2014 03:33 PM, Wayne Stambaugh wrote: On 03/14/2014 10:24 AM, Adam Wolf wrote: Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. That's a rather sad statement. Before the advent of the GUI (I know I am showing my age), even the secretary (...) Hi Wayne, In my humble opinion, it's not a matter of technical competence, but the first impression that Kicad makes on the first-time user. Most people expect software to work more or less out of the box, even the advanced ones (that's why among proprietary tools me my folks @ CERN prefer Altium over Cadence, despite the latter being much more powerful). When somebody buys a Mac, the usual reason is it to avoid having to edit config files. I know many extremely competent analog designers who simply use autotrax or old orcad, just because they didn't require any configuration. 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? Cheers, Tom ___ 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
Re: [Kicad-developers] Local Variables
On 03/14/2014 10:00 AM, Adam Wolf wrote: I'm working a bit more than an hour a day on the Mac and Ubuntu/Debian/32bit/64bit capable of being used as Debian/Ubuntu official automation effort, but about half of that time is waiting for things to complete, so I'm looking for a little more Kicad work. Aren't you a python jockey? Maybe offer to be Dileep's mentor, and see if he will accept your help in working on milestone C). He actually needs someone to do that for his university work, might require a signature at the end. Practically, he will need some help, so if you have the experience, I think he should accept a generous offer from you to help. As I said, I would join your team around the completion of milestone B). Tucking in some C++ magic under your wxPython work, into the top of the KIWAYs, plural. We need a *multi-project* interface, one that shows all open projects as different from closed projects, and symbolic buttons or panel-lettes which show the open KIFACE tools, such as pcbnew or eeschema, or future. It needs to be able to launch pcbnew or eeschema on any project, and classify it as open thereafter in the GUI. (Isolate the launching code, it will get replaced later with a Kiway interface. Simply chain load kicad and pcbnew exes for now.) After KIWAY inclusion, we can then add a bring to top function. We need a place to hook in an ever expanding set of utilities, conversion scripts, and project front ends, gateways to other EDA tools, etc. This will give the stature from which to add more SWIG interfaces in the DLL/DSOs below. Anything else you can think of. Dick ___ 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
Re: [Kicad-developers] Local Variables
I strongly agree with Tomasz, helping the user just firsts steps just after the download is the key for a quick adoption. When someone downloads Kicad for the first time is because have an idea in mind that wish to trasfer in the reality or just to comparate its software with the OpenSource one. My humble opinion is that this programmer-centric approach to the GUI is the one that hasn't permitted Linux to be a new reference for the desktop systems. Wayne, at the DOS time the default interface was the CLI, so was cooerent for an user being able to set those, like now could be coerent on windows for an user handle the registry keys. If really we wish being able in the future to try a port to a Tablet, also if only as a reader, we can't require users to set enviroment variables by hand, they could not be able to do it. I personally think that Preferences could be the old good standard way to place the variables now stored in the enviroment, then those could be stored in the .pro files, Easy, straight and following a KISS approach. Mac has enviroment variables but those are thinked to be used for command line commands in a terminal and there isn't a standard way to make them set, as anything not directly stated by Apple, each interface you use, can change between releases or also with a patchset, OSX users/programmers know that and are strict to follow the guidelines, this is a cathedral approach. I personally think also that the Tomasz interface should be done in C++, the first setup should be rock solid and failsafe: is the first fly, we can reasonably expect issues with python on the first fly, probably is the place where we could test and exercize the enviroment before leaving the control to the User. Is the first place we could fail and loose a new adopter. I know, there is a new toy python and all us are happy of that and wish play a bit, but i personally think that the first setup interface is the homeworks that prepare to go to play after quietly. -- Marco On Fri, Mar 14, 2014 at 4:11 PM, Tomasz Wlostowski tomasz.wlostow...@cern.ch wrote: On 03/14/2014 03:33 PM, Wayne Stambaugh wrote: On 03/14/2014 10:24 AM, Adam Wolf wrote: Hi folks, I heartily agree with this. I've been trying to show some Kicad users how to use new features in Kicad, and environment variables is turning out to be a real turn-off for many of them. That's a rather sad statement. Before the advent of the GUI (I know I am showing my age), even the secretary (...) Hi Wayne, In my humble opinion, it's not a matter of technical competence, but the first impression that Kicad makes on the first-time user. Most people expect software to work more or less out of the box, even the advanced ones (that's why among proprietary tools me my folks @ CERN prefer Altium over Cadence, despite the latter being much more powerful). When somebody buys a Mac, the usual reason is it to avoid having to edit config files. I know many extremely competent analog designers who simply use autotrax or old orcad, just because they didn't require any configuration. 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? Cheers, Tom ___ 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
Re: [Kicad-developers] Local Variables
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 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
Re: [Kicad-developers] Local Variables
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
Re: [Kicad-developers] Local Variables
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. When I build from source with minimum interaction (cake, make, make install), /demos and /templates ends-up in /usr/local/share/kicad/. 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. What is the best route to do just that? 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
Re: [Kicad-developers] Local Variables
Adam, That’s a good news indeed. I will try to figure out the parameters to set to have cmake generate the right path for the make install, so we will be able to customize your script to end up with a good DMG package that install all the executables. Another script could be created to install the libraries. I will work with you on that issue. Jean-Paul (AC9GH) Electronic Manufacturing Engineering Manager (retired). On Mar 14, 2014, at 10:16 PM, Adam Wolf adamww...@gmail.com wrote: I have a script that takes all the .app files and puts them in a DMG, adds a readme, and converts it to a compressed DMG, all with pretty icons like Mac applications are normally distributed. This doesn't fix any path issues in and of itself, but it's part of what we need for Mac nightlies. I'll be posting it shortly. Adam Wolf Wayne and Layne LLC On Mar 14, 2014 8:17 PM, Jean-Paul Louis lou...@yahoo.com 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. When I build from source with minimum interaction (cake, make, make install), /demos and /templates ends-up in /usr/local/share/kicad/. 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. What is the best route to do just that? 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
