kicad-developers team mailing list archive

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

2014-08-05 2:13 GMT+02:00 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.

I see the path is set with set3DShapesPath( const wxString&
aKiSys3Dmod ) in pcbnew/pcbnew.cpp

Ahh, and now I realised that it is because the path also has to exist,
so setting a random string will not work. The check is:

if( wxGetEnv( aKiSys3Dmod, &path ) && wxFileName::DirExists( path ) )
return true;

So basically, it was me doing it wrong. Sorry for the noise.

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