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)? 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" <[email protected]> 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 Fileskicad 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 <[email protected] >>> <mailto:[email protected]>> 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" <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> 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" >>>>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> 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 >>> [1] >>>>>> >>>>>> 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 [2] >>>>>>> Post to : [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers [2] >>>>>>> More help : https://help.launchpad.net/ListHelp [3] >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers [2] >>>>>> Post to : [email protected] >>> <mailto:[email protected]> >>>>>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers [2] >>>>>> More help : https://help.launchpad.net/ListHelp [3] >>>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers [2] >>>>> Post to : [email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers [2] >>>>> More help : https://help.launchpad.net/ListHelp [3] >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers [2] >>>> Post to : [email protected] >>> <mailto:[email protected]> >>>> Unsubscribe : https://launchpad.net/~kicad-developers [2] >>>> More help : https://help.launchpad.net/ListHelp [3] >>>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers [2] >>> Post to : [email protected] >>> <mailto:[email protected]> >>> Unsubscribe : https://launchpad.net/~kicad-developers [2] >>> More help : https://help.launchpad.net/ListHelp [3] >>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers [2] >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers [2] >> More help : https://help.launchpad.net/ListHelp [3] Links: ------ [1] https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/LaunchServicesKeys.html#//apple_ref/doc/uid/20001431-106825 [2] https://launchpad.net/~kicad-developers [3] https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
