kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: 
> Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, August 5, 2014 9:24 AM
> Subject: Re: [Kicad-developers] 3D modules path strange behaviour
> 
> On 8/4/2014 12:02 PM, Nick Østergaard wrote:
>>  2014-08-04 16:00 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>:
>>>  On 8/4/2014 7:34 AM, yann jautard wrote:
>>>> 
>>>>  Le 04/08/2014 10:57, Nick Østergaard a écrit :
>>>>>  2014-08-04 10:00 GMT+02:00 yann jautard 
> <bricofoy@xxxxxxx>:
>>>>> 
>>>>>>  And also what about the path to the 3D models directory 
> that cannot be
>>>>>>  edited ? Is there a place where we can edit it ?
>>>>>  That is a bug I believe, it is supposed to be set with an 
> environment
>>>>>  variable, but I guess it is just not catched anywhere.
>>>> 
>>>>  I noticed also we can't edit the KIPRJMOD and KISYSMOD 
> variables related
>>>>  to the library table. I'm not sure that this should me 
> environnement
>>> 
>>>  You can edit KIPRJMOD, KISYSMOD, AND KISYS3DMOD.  They are environment
>>>  variables so you have to edit them either system wide or user specific
>>>  depending on your needs using your preferred method for editing
>>>  environment variables on your system.  You are not obligated to use any
>>>  of these variables.  You can specify the full path and/or file name
>>>  (depending on the library type) for each library.
>> 
>>  Well, that is the thing... it does not work for me to define a
>>  KISYS3DMOD environment variable. I does not seem to be defined anywere
>>  already on my sytem, when I echo $KISYS3DMOD it is empty. But if I try
>>  to export it in a new terminal session as "export 
> KISYS3DMOD=foo", I
>>  do get foo when I echo it -- as expected, but kicad do not catch this.
>>  I open pcbnew from the same terminal as I set the env var in, then add
>>  a random footprint to the canvas, open the properties for it, then I
>>  go to the 3D settings tab, here the path is still listed as
>>  "/usr/share/kicad/modules/packages3d", which I expected to be 
> "foo". I
>>  am on Archlinux, with 5041.
> 
> Environment variable defined in a shell session are only visible to
> applications launched from within that shell session.  It has to be
> defined before or when you log in as a user to always be visible.
> Typically you would define it in ~/.profile or for all users in one of
> the scripts or your own custom script in /etc/profile.d.  Although this
> can vary from distro to distro.
> 
>> 
>>  Also in that regard I cannot use custom enviroment variables in the
>>  "3D Shape Name" list IIRC. (at least last time I tested, I did 
> not
>>  test this now, I can do that if requested)
> 
> This may be a limitation of the 3D software design.  I didn't write any
> of this so I cannot say one way or another if 3D model file paths accept
> the %ENV_VAR%/rest/of/path notation.  The footprint library table will
> accept any environment variable.
> 
> 


The use of the variable KISYS3DMOD is hard-coded; this is due to the fact
that there is no configuration file similar to fp-lib-table used by the
3D code. The environment variable was introduced as a quick fix to the 3D
code after the old path resolution system was removed.

Personally I support the current use where KISYS3DMOD can be set to point
to the root of the old 3D models directory so that we have the behavior
which was present before the changes in the path resolution code. Any
further changes will have to be carefully thought out and are likely to
affect the GUI as well. For example let's say we have PathA, PathB, PathC
for 3D models. When you want to associate a model in one of those paths,
how does the file dialog offer you the convenience to quickly select one
of those? If you only have a partial path such as a relative path and
it's valid for PathA, PathB, PathC, then what do you do? We essentially
have the same broken behavior as in eeschema. At the moment I prefer to
live with the old familiar problems than to hastily implement something
which will be even worse. The current system, despite its shortcomings,
works for me and in my mind improving it will actually require substantial
work. If someone wants to plan and execute that work I'm sure many users
will be grateful, but personally I don't see it as being important enough
for me to spend time on.

- Cirilo