← Back to team overview

kicad-developers team mailing list archive

Re: PATCH: Setting OS X KISYSMOD value in bundle

 

 

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" <stambaughw@xxxxxxxxx> 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 <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> 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" <majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>
>>>> <mailto:majopela@xxxxxxxxxx <mailto:majopela@xxxxxxxxxx>>> 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"
>>>>> <stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>
>>> <mailto:stegmaier@xxxxxxxxxxxxx <mailto:stegmaier@xxxxxxxxxxxxx>>>
>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> 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 : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> 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

Follow ups

References