kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/14/2015 1:41 PM, Nick Østergaard wrote:
> 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.

Use the edit filename button (see attachment).  It's less than elegant
but you do not need to use an external text editor.

> 
>>> 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}

Would you bet your life on this?  This may be what you think it should
be relative to.  Others may not have the same expectation.

> 
>>> 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

Attachment: env-var-in-3d-shape-name.png
Description: PNG image