On 1/8/2015 11:21 AM, Bernhard Stegmaier wrote: > Hi all, > > you are right... if its not mandatory to use KISYSMOD, but someone can > use any other variable (like Wayne does), then I wouldn't care about a > "hard" set value (just take my own one if pre-defined doesn't fit). And > one reasonable fixed path probably would fit 95% percent of users... > > I don't remember the code exactly... is it the same for KISYS3DMOD, > i.e., I can use any custom variable to point my modules to my 3d-modules > (I guess the "path" to 3d module is also only given to variable > expansion so basically it doesn't matter how the variable is called)?
KISYS3DMOD is a special case (for now). It is the only environment variable expanded for 3D model library paths. There is no concept of a 3D model library table yet. Only the footprint library table supports environment variable expansion for any user defined variable. > > If both is the case I don't have any objections against having those > paths set in the bundle for now... > > > > Regards, > Bernhard > > > > > > On 2015-01-08 16:40, Adam Wolf wrote: > >> Hi Wayne, >> >> Thank you for wearing all those hats! It makes you a pleasure to work >> with. >> >> I am not familiar with the path dialog work. From what I can infer, >> it sounds great--even better than default environment variable values >> is something users can see and modify without restarting Kicad. >> >> If we have a solid plan going forward for this, I feel even better >> about putting a custom patch for the environment variable in the mac >> nightlies, in the interest of serving users and not delaying the >> nightlies release any sooner. As soon as the path dialog stuff is >> ready, we can pull the custom patch and provide a transition for users >> if needed. (I don't expect there would be...) >> >> Currently, any custom patches are listed in the README automatically. >> >> I would not feel as good about putting custom patches in for the >> upcoming stable release. >> >> Bernhard, folks, what do you think? Is this a reasonable option? >> >> Adam Wolf >> >> Cofounder and Engineer >> >> W&L >> >> On Jan 8, 2015 9:15 AM, "Wayne Stambaugh" <stambau...@gmail.com >> <mailto:stambau...@gmail.com>> wrote: >> >> On 1/8/2015 9:43 AM, Adam Wolf wrote: >> > Hi Wayne, >> > >> > When dealing with Kicad's internals, I often have the >> perspective of a >> > packager, and sometimes that makes me have weird ideas. >> >> As a developer, packager, and user I have the same issues. What >> is good >> for development purposes is not always the best for packaging or >> use and >> vice-versa. Finding a good balance is more difficult than one >> would think. >> >> > >> > I remember the search path discussions and the issues where it was >> > impossible to tell which footprint got picked. I don't want to >> bring >> > that back. >> > >> > Right now, KISYS3DMOD has a default value defined in code if the >> > environment variable isn't set. What about if there is a >> default value >> > for all of the standard environment variables? >> > >> > I'm not sure what everyone else thinks, but defining those default >> > values in CMake might actually be a good idea--then packagers >> can modify >> > them without patching, but it wouldn't be a problem either if we >> just >> > split it up into Lin/Win/OSX sections in the code. >> >> I plan on setting the default paths and environment variables as >> part of >> the path dialog work. I will most likely use the paths generated by >> CMake as the defaults. This should work in most cases and will >> work in >> every case when `cmake install` is used to install kicad. The only >> place I see an issue is the windows installer. By default cmake sets >> the install path on windows to c:\Program Files\kicad or c:\Program >> Files (x86)\kicad. If the user chooses to change the install >> path, the >> default path settings would be wrong. There are several ways around >> this that are very windows specific and each having it's own set >> of issues. >> >> > >> > Adam Wolf >> > Cofounder and Engineer >> > W&L >> > >> > On Thu, Jan 8, 2015 at 7:44 AM, Wayne Stambaugh >> <stambau...@gmail.com <mailto:stambau...@gmail.com> >> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote: >> > >> > Fully defined paths can be used in the fp-lib-table if that >> is your >> > preference. Environment variable substitution is optional. >> You are >> > free to use any environment variable you want. KISYSMOD is >> merely the >> > variable name used for the default footprint library path. >> I use >> > KILCLMOD to point to the path of my custom footprint >> libraries. I set >> > these paths to the same disk partition and and path in both >> windows and >> > linux so I'm always using the same footprint libraries when I'm >> > developing on either platform. >> > >> > On 1/8/2015 8:33 AM, Adam Wolf wrote: >> > > Maybe. For KISYSMOD, I am not sure if it is used anywhere >> in the source. >> > > >> > > I do not think your work around would work for KISYS3DMOD, >> though. >> > > >> > > On Jan 8, 2015 7:29 AM, "Miguel Ángel Ajo" >> <majop...@redhat.com <mailto:majop...@redhat.com> >> <mailto:majop...@redhat.com <mailto:majop...@redhat.com>> >> > > <mailto:majop...@redhat.com <mailto:majop...@redhat.com> >> <mailto:majop...@redhat.com <mailto:majop...@redhat.com>>>> wrote: >> > > >> > > Can’t users just change that reference to their own >> path on their >> > > own fp-lib-table >> > > instead of the ENV var reference if they don’t want >> the system modules? >> > > >> > > That would be reasonable enough to me. >> > > >> > > >> > > >> > > Miguel Ángel Ajo >> > > >> > > On Thursday, 8 de January de 2015 at 13:53, Adam Wolf >> wrote: >> > > >> > >> I hear what you're saying. >> > >> >> > >> I don't really like the idea of using environment >> variables to >> > >> drive the behavior of GUI programs, especially in OS >> X. They're >> > >> tricky in OS X, and they're hard to explain to a lot >> of users. >> > >> >> > >> Fixing this through changing the behavior of how >> KISYSMOD and >> > >> probably the other environment variables work in >> Kicad is probably >> > >> a fair bit of work, at least a week or two--when you >> include >> > >> developer discussion, regression testing on other >> platforms, stuff >> > >> like that, probably even longer. >> > >> >> > >> I'm not 100% happy about it, but would something like >> this be an >> > >> OK stopgap measure while we figure out the right >> thing moving >> > >> forward? I am fine only putting this patch in my builds. >> > >> >> > >> Adam Wolf >> > >> Cofounder and Engineer >> > >> Wayne and Layne >> > >> >> > >> On Jan 8, 2015 6:26 AM, "Bernhard Stegmaier" >> > >> <stegma...@sw-systems.de >> <mailto:stegma...@sw-systems.de> <mailto:stegma...@sw-systems.de >> <mailto:stegma...@sw-systems.de>> >> > <mailto:stegma...@sw-systems.de >> <mailto:stegma...@sw-systems.de> <mailto:stegma...@sw-systems.de >> <mailto:stegma...@sw-systems.de>>>> >> > wrote: >> > >>> __ >> > >>> >> > >>> Hi Adam, hi all, >> > >>> >> > >>> that IMHO could be problematic (depends on what you >> intend >> > to have). >> > >>> >> > >>> For a single-user environment this might be OK, but >> it then >> > >>> forces modules to be in a machine specific folder >> common to all >> > >>> users. In a multi-user environment you probably >> might not >> > want to >> > >>> have that. And, I never read somewhere that you can >> override >> > this >> > >>> setting of the bundle somehow, so this could be a >> once and for >> > >>> all decision (as long as you don't fiddle around >> with the >> > >>> Info.plist) and you wouldn't need an environment >> variable at >> > all... >> > >>> Further, I think I tried once to use "~" or "$HOME" in >> > Info.plist >> > >>> but it doesn't expand such variables. So, you obviously >> > can't set >> > >>> the path to something in user home with this method. >> > >>> Last, I don't know if always any (non-root) user is >> allowed to >> > >>> write into /Library/Application Support/kicad? >> > >>> >> > >>> In my opinion, the old concept of search paths did >> fit such >> > >>> hardcoded paths much better than it is currently with >> > environment >> > >>> variables. If environment variables are too hard to >> set, then >> > >>> probably a configuration setting directly from some >> "Settings" >> > >>> menu would be better. >> > >>> >> > >>> My opionion: I wouldn't want to have it that way, >> but since I am >> > >>> the only one using KiCad on my machines I can also >> live with >> > some >> > >>> links pushing things into the spot I want to have it. >> > >>> >> > >>> This altogether is somewhat inconsistent, because >> eeschema will >> > >>> *always* look in <base>/library with <base> being >> (in that >> > order): >> > >>> * $KICAD >> > >>> * ~/Library/Application Support >> > >>> * /Library/Application Support >> > >>> * <kicad.app>/Contents/SharedSupport >> > >>> >> > >>> So, if the path should be fixed for pcbnew, I would >> at least >> > >>> expect eeschema to behave the same way (i.e., >> removing all the >> > >>> other paths and also pointing it to the one global >> > >>> /Library/Application/Support/kicad/library). >> > >>> >> > >>> >> > >>> >> > >>> Regards, >> > >>> Bernhard >> > >>> >> > >>> PS: >> > >>> >> > >>> I just had a brief look at the Apple docs and did >> see here >> > >>> >> > >>> >> > >> >> https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/20001431-106825 >> > >>> >> > >>> that obviously the environment set in the Info-plist >> is only >> > >>> valid when launching via an icon, but not via >> command-line: >> > >>> <<< >> > >>> These environment variables are set only for apps >> launched >> > >>> through Launch Services. If you run your executable >> directly >> > from >> > >>> the command line, these environment variables are >> not set. >> > >>> >>> >> > >>> >> > >>> So, another issue that already now with the KIGITHUB >> variable >> > >>> might lead to confusion... >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> On 2015-01-08 06:52, Adam Wolf wrote: >> > >>> >> > >>>> Hi folks, >> > >>>> >> > >>>> As you may know, it's harder than it seems to set an >> > environment >> > >>>> variable on a bundle in OS X as a user. >> > >>>> >> > >>>> I have a patch here for the OS X bundle that sets >> KISYSMOD to >> > >>>> /Library/Application Support/kicad/modules >> > >>>> >> > >>>> Please let me know if there are any questions or >> comments. >> > >>>> >> > >>>> Thanks! >> > >>>> >> > >>>> Adam Wolf >> > >>>> Cofounder and Engineer >> > >>>> W&L >> > >>>> >> > >>>> _______________________________________________ >> > >>>> Mailing list: https://launchpad.net/~kicad-developers >> > >>>> Post to : kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net>> >> > <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto: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 >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net>> >> > >>> <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto: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 >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net>> >> > >> <mailto:kicad-developers@lists.launchpad.net >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto: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 >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto: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 >> <mailto:kicad-developers@lists.launchpad.net> >> > <mailto: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 >> <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
