kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2015-09-14 19:05 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
> On 9/14/2015 10:29 AM, easyw@xxxxxxxxxxxx wrote:
>> Hi,
>> moreover it seems that $KIPRJMOD variable is not understood when
>> changing a path in 3D model selection that has already that value
>> configured
>> (Footprint Properties, 3D settings, 3D shape name)
>
> Are you saying using ${KIPRJMOD}/my3dmodel.wrl in the 3D shape name does
> not work?  If not, I'm not sure what you are describing here.

You can not edit the path field in the GUI. And the add shapes file
browser does not let you add it.

>> It would be also useful to use/insert '$KIPRJMOD' variable when choosing
>> relative path.
>> Relative path is NOT working in windows.
>
> Relative path don't work anywhere except in a few carefully controlled
> situations.  The problem with relative paths is what path are the
> actually relative to.

${KIPRJMOD}

>> At the moment the variable, in my knowledge, can be put only by hand
>> with a text editor.
>
> Which files are you talking about?  AFAIK, you can add any environment
> variable expansion ${ENV_VER} to a 3D footprint in the footprint editor.

I did it only on the kicad_pcb file, I have not actually set the
property for the footprint.

>>
>> On 9/14/15 5:31 AM, Cirilo Bernardo wrote:
>>> Hi folks,
>>>
>>>   I was just looking into how KiCad currently handles partial paths for
>>> files and I have found:
>>>
>>> (a) 3D model paths are now resolved exclusively via the KISYS3DMOD
>>> environment variable
>>>
>>> (b) kiface_i.cpp contains what appears to be some dead code:
>>> (lines 64 - 76):
>>>
>>>          // Add PCB library file path to search path list.
>>>          if( aId == KIWAY::FACE_PCB || aId == KIWAY::FACE_CVPCB )
>>>          {
>>>              fn.AppendDir( wxT( "modules" ) );
>>>              aDst->AddPaths( fn.GetPath() );
>>>
>>>              // Add 3D module library file path to search path list.
>>>              fn.AppendDir( wxT( "packages3d" ) );
>>>              aDst->AddPaths( fn.GetPath() );
>>>
>>>              fn.RemoveLastDir();
>>>              fn.RemoveLastDir();     // "../../" up twice, remove
>>> modules/packages3d
>>>          }
>>>
>>> While I haven't checked if "modules" is used (I presume it is since
>>> schematic
>>> symbols are there), I don't believe the "packages3d" directory is ever
>>> searched
>>> via the SEARCH_STACK object. I suggest we remove the lines 70..74:
>>>              // Add 3D module library file path to search path list.
>>>              fn.AppendDir( wxT( "packages3d" ) );
>>>              aDst->AddPaths( fn.GetPath() );
>>>
>>>              fn.RemoveLastDir();
>>>
>>> My reasons are (1) anyone who's already set up to use 3D models is
>>> no doubt using KISYS3DMOD and (2) the 3D code in my refactoring
>>> branch will have its own configuration file containing path roots for
>>> 3D models and will not use SEARCH_STACK anyway. (Then again
>>> I can always make a small change to use SEARCH_STACK.)
>>>
>>> Another suggestion for SEARCH_STACK: there are obviously a
>>> few hard-coded assumptions about paths and paths are added
>>> without checking that (a) they exist and (b) they are directories.
>>> If we eliminate candidate paths which do not exist or are not
>>> directories then we may save some time otherwise wasted
>>> searching non-existent paths; this will also avoid the error which
>>> I frequently get complaining about items not being available
>>> in non-existent paths.
>>>
>>> - Cirilo