Re: [Kicad-developers] 3D file relative paths
I propose to make the following improvements to the 3D resolver code:
1. Environment var paths defined by kicad should be added to the
drop-down list for model selection.
IMO that would be a very useful feature
Maurice
On 14/04/2016 00.09, Cirilo Bernardo wrote:
I agree there should be no Debian policy violation here. I was unaware
of the "Configure Paths" scheme for defining environment variables
though. I'll look at the docs and see if there is any mention of using
the configured paths with 3D models.
I propose to make the following improvements to the 3D resolver code:
1. Environment var paths defined by kicad should be added to the
drop-down list for model selection. The list should probably be culled
with a simplistic check - anything with "://" in the name will not be
added (at least not until we have developed some scheme for
retrieving these files) and paths which end in "template{/}" will not
be added. Other paths may or may not correspond to model directories
but typically not many paths are defined so I think the benefits for
ease of browsing outweigh the nuisance of extra paths in the list.
2. Environment paths will have precedence over alias paths when a
filename is shortened. The use of ENV_VAR is compatible with
earlier versions of kicad while the use of aliases is not. While there
has technically been no change in the file format structure, the use
of aliases has essentially introduced a file format change (I didn't
really realize this before).
3. For compatibility with earlier versions, files within the current
working directory will be prefixed with ${KIPRJMOD}. Currently
such files do not have a prefix at all, they are simply partial
paths which must be resolved relative to the project directory,
which breaks compatibility with earlier versions.
Items 1-3 raise the question: is there any benefit in keeping the
alias scheme at all or would it be better to drop it and use
${ENV_PATH} definitions instead? I have no great attachment to
the scheme since it's only a minor part of the 3D refactor. On the
one hand we can argue against breaking compatibility with
earlier versions, but on the other hand we can argue that the
previous behavior is somewhat cumbersome and should be
supplanted.
One outstanding item to resolve:
Some users would like to specify 3D files relative to the current
project directory; with the current behavior of the resolver, any paths
which are not a descendant of an alias path are converted into
an absolute path. Should I provide a switch to decide between
absolute and relative to current project? In this particular instance
I can't think of a strong argument to allow relative paths since that
would cause a nightmare if a project directory is moved in the
filesystem. On the other hand do we really want to tell users
"use sed to convert to relative paths before you send a project to
another team member".
- Cirilo
On Thu, Apr 14, 2016 at 3:16 AM, Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:
On 4/13/2016 12:04 PM, Simon Richter wrote:
> Hi,
>
> On 13.04.2016 02:40, David Godfrey wrote:
>
>> The use of Env Vars is the only sensible and portable method
that can be
>> used.
>
> From a distribution point of view: this is unusable. We need to ship
> something that can be started from a desktop icon, without extra
setup,
> and users need to be able to configure everything from the UI,
because
> we cannot expect them to learn how environment variables are set
this week.
>
> Debian policy explicitly forbids this, for a reason.
>
>Simon
No system or user level environment variables need to be set so there
should be no Debian policy violation. All environment variables are
user configurable with kicad, are set per process, and have platform
specific defaults that work for clean installs. System and user level
environment variables can be used at the discretion of the user but are
not required.
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_
Re: [Kicad-developers] 3D file relative paths
I agree there should be no Debian policy violation here. I was unaware
of the "Configure Paths" scheme for defining environment variables
though. I'll look at the docs and see if there is any mention of using
the configured paths with 3D models.
I propose to make the following improvements to the 3D resolver code:
1. Environment var paths defined by kicad should be added to the
drop-down list for model selection. The list should probably be culled
with a simplistic check - anything with "://" in the name will not be
added (at least not until we have developed some scheme for
retrieving these files) and paths which end in "template{/}" will not
be added. Other paths may or may not correspond to model directories
but typically not many paths are defined so I think the benefits for
ease of browsing outweigh the nuisance of extra paths in the list.
2. Environment paths will have precedence over alias paths when a
filename is shortened. The use of ENV_VAR is compatible with
earlier versions of kicad while the use of aliases is not. While there
has technically been no change in the file format structure, the use
of aliases has essentially introduced a file format change (I didn't
really realize this before).
3. For compatibility with earlier versions, files within the current
working directory will be prefixed with ${KIPRJMOD}. Currently
such files do not have a prefix at all, they are simply partial
paths which must be resolved relative to the project directory,
which breaks compatibility with earlier versions.
Items 1-3 raise the question: is there any benefit in keeping the
alias scheme at all or would it be better to drop it and use
${ENV_PATH} definitions instead? I have no great attachment to
the scheme since it's only a minor part of the 3D refactor. On the
one hand we can argue against breaking compatibility with
earlier versions, but on the other hand we can argue that the
previous behavior is somewhat cumbersome and should be
supplanted.
One outstanding item to resolve:
Some users would like to specify 3D files relative to the current
project directory; with the current behavior of the resolver, any paths
which are not a descendant of an alias path are converted into
an absolute path. Should I provide a switch to decide between
absolute and relative to current project? In this particular instance
I can't think of a strong argument to allow relative paths since that
would cause a nightmare if a project directory is moved in the
filesystem. On the other hand do we really want to tell users
"use sed to convert to relative paths before you send a project to
another team member".
- Cirilo
On Thu, Apr 14, 2016 at 3:16 AM, Wayne Stambaugh
wrote:
> On 4/13/2016 12:04 PM, Simon Richter wrote:
> > Hi,
> >
> > On 13.04.2016 02:40, David Godfrey wrote:
> >
> >> The use of Env Vars is the only sensible and portable method that can be
> >> used.
> >
> > From a distribution point of view: this is unusable. We need to ship
> > something that can be started from a desktop icon, without extra setup,
> > and users need to be able to configure everything from the UI, because
> > we cannot expect them to learn how environment variables are set this
> week.
> >
> > Debian policy explicitly forbids this, for a reason.
> >
> >Simon
>
> No system or user level environment variables need to be set so there
> should be no Debian policy violation. All environment variables are
> user configurable with kicad, are set per process, and have platform
> specific defaults that work for clean installs. System and user level
> environment variables can be used at the discretion of the user but are
> not required.
>
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
On 4/13/2016 12:04 PM, Simon Richter wrote: > Hi, > > On 13.04.2016 02:40, David Godfrey wrote: > >> The use of Env Vars is the only sensible and portable method that can be >> used. > > From a distribution point of view: this is unusable. We need to ship > something that can be started from a desktop icon, without extra setup, > and users need to be able to configure everything from the UI, because > we cannot expect them to learn how environment variables are set this week. > > Debian policy explicitly forbids this, for a reason. > >Simon No system or user level environment variables need to be set so there should be no Debian policy violation. All environment variables are user configurable with kicad, are set per process, and have platform specific defaults that work for clean installs. System and user level environment variables can be used at the discretion of the user but are not required. > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
Hi, On 13.04.2016 02:40, David Godfrey wrote: > The use of Env Vars is the only sensible and portable method that can be > used. From a distribution point of view: this is unusable. We need to ship something that can be started from a desktop icon, without extra setup, and users need to be able to configure everything from the UI, because we cannot expect them to learn how environment variables are set this week. Debian policy explicitly forbids this, for a reason. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
Hi Maurice,
I will work out how to put in an exception to preserve the ${ENV_VAR}. The
current behavior unintentionally breaks the previous kicad behavior.
- Cirilo
On Tue, Apr 12, 2016 at 8:46 PM, easyw wrote:
> Hi Cirilo,
>
> please consider to let users to use also $ENVAR
> with the new 3D refactor $ENVAR variables (ie.e KIPRJMOD) are still
> interpreted but cannot edited
>
> if you want to make a change to a model name still including i.e.
> KIPRJMOD, the pcbnew dialog will reject it, forcing the user to drop $ENVAR
> Error message: Invalid filename
>
> Maurice
>
>
> On 12/04/2016 08.18, Cirilo Bernardo wrote:
>
>> Hi folks,
>>
>> The current behavior of the 3D filename resolver is to use
>> an absolute path in instances where a specified path is
>> not a descendant of a path within the aliased paths list
>> (that is, the filename cannot be shortened using an existing
>> alias). This decision was originally made to avoid ambiguous
>> relative paths such as "../../some/path" (what is it
>> relative to?). The obvious down side of course is that
>> absolute paths are not portable and this scheme would
>> be a nuisance to people who want to share their work
>> somehow. Since a number of people seem to be reliant
>> on using the "../" form of relative path to share their work,
>> I'd like to know people's opinions on using such relative
>> paths. If such relative paths are preferred to absolute
>> paths then I can make changes to the code such that
>> the resolver will assign a path relative to the Current
>> Project Directory rather than an absolute path in cases
>> where the file path cannot be shortened via the use of
>> an alias.
>>
>>
>> - Cirilo
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
Hi Wayne and Cirilo,
I have to agree with Wayne here.
The use of Env Vars is the only sensible and portable method that can be
used.
If using relative paths that are relative to the project dir, and I want
to put a collection of footprints (etc) in some other dir, perhaps on a
server share, the relative path model then fails.
However there is no reason why I can't have appropriate Env Vars set in
the Configure Paths dialog to facilitate that, or even more complex
arrangements.
I think both use and editing of File location should handle env vars
sensibly.
If editing, I would expect to be able to enter any env var, and get a
warning (but only a warning) on saving the change if the env var is not set.
Display of the File Location should show the uninterpreted env var. ie
${ProjDir}/demo.pcb
Regards
David G
On 13/04/16 07:02, Wayne Stambaugh wrote:
> It's not necessary to define environment variable at the system wide or
> user level. You can define them at the application level using the
> "Configure Paths" dialog. This way you can set any environment variable
> you want and it will be available in the currently running process.
> Configured properly, it should allow you to make your projects portable
> across systems and platforms assuming you can access all of your
> libraries on a given system. This is how I do it.
>
> On 4/12/2016 5:32 PM, Cirilo Bernardo wrote:
>> Hi Wayne,
>>
>> The new resolver will expand variable names; any path specified in a
>> kicad pcb file or footprint file will be interpreted in exactly the same
>> way as with the older system. The only difference with the new system is
>> that there is no need for environment variables (but they will be
>> interpreted if present). The idea was that users could use the GUI to
>> specify the search paths and give those paths names (aliases) which are
>> analogous to the environment variables, except that they aren't
>> environment variables. I think this is a Good Thing because fiddling
>> with environment variables on MSWin and OSX is a nuisance. I imagine
>> some Linux users might find env vars a nuisance as well, especially if
>> they launch kicad from a desktop UI.
>>
>> I'll check out the issue with the software rejecting ${ENV_VAR} in the
>> file name editor.
>>
>> If we agree that a "../" style of relative path can only be interpreted
>> as relative to the current project directory then I think that style of
>> relative path may in fact be better in many ways than an absolute path
>> (until a user moves the project directory). Some users prefer that
>> style of relative path for their particular workflow so I can implement
>> that if there are no objections.
>>
>> The other differences between the new resolver and the old system:
>> a. a partial path like "path/to/my/file.wrl" will be interpreted as a
>> path within the current working directory (new behavior) and if it
>> doesn't exist there then it will be interpreted as a path within the
>> ${KISYS3DMOD} directory (old behavior).
>> b. due to the new behavior in (a), there is no need for "${KIPRJMOD}" -
>> a partial path will always be checked against the current project directory.
>>
>> So a summary of the new resolver:
>> a. env vars are not needed, but still supported (except for the issue
>> mentioned in the filename editor)
>> b. multiple model root paths are supported via aliases rather than env
>> var; an aliased name appears to the user as
>> "alias_name:my/partial/path/to/mymodel.wrl"; within the PCB file the
>> alias itself appears as ":alias_name:my/partial/path/to/mymodel.wrl".
>>
>> - Cirilo
>>
>> On Tue, Apr 12, 2016 at 10:54 PM, Wayne Stambaugh > > wrote:
>>
>> Hey Cirilo,
>>
>> Does the new 3D file path resolve no longer support environment variable
>> expansion? If it doesn't, it should. We've have had so many issues
>> with relative paths in the past that I'm reluctant to allow them.
>> That's the primary reason we support environment variable expansion in
>> the fp-lib-table and the old 3D file path code because it's infinitely
>> more portable than relative and absolute paths. I know this is not the
>> easiest issue to resolve but the best solution I've seen is how
>> fp-lib-table handles them. If someone has any better ideas, I'm open to
>> suggestion.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 4/12/2016 2:18 AM, Cirilo Bernardo wrote:
>> > Hi folks,
>> >
>> > The current behavior of the 3D filename resolver is to use
>> > an absolute path in instances where a specified path is
>> > not a descendant of a path within the aliased paths list
>> > (that is, the filename cannot be shortened using an existing
>> > alias). This decision was originally made to avoid ambiguous
>> > relative paths such as "../../some/path" (what is it
>> > relative to?). The obvious down side of course is that
>> > absolute paths are not portable and this scheme
Re: [Kicad-developers] 3D file relative paths
It's not necessary to define environment variable at the system wide or
user level. You can define them at the application level using the
"Configure Paths" dialog. This way you can set any environment variable
you want and it will be available in the currently running process.
Configured properly, it should allow you to make your projects portable
across systems and platforms assuming you can access all of your
libraries on a given system. This is how I do it.
On 4/12/2016 5:32 PM, Cirilo Bernardo wrote:
> Hi Wayne,
>
> The new resolver will expand variable names; any path specified in a
> kicad pcb file or footprint file will be interpreted in exactly the same
> way as with the older system. The only difference with the new system is
> that there is no need for environment variables (but they will be
> interpreted if present). The idea was that users could use the GUI to
> specify the search paths and give those paths names (aliases) which are
> analogous to the environment variables, except that they aren't
> environment variables. I think this is a Good Thing because fiddling
> with environment variables on MSWin and OSX is a nuisance. I imagine
> some Linux users might find env vars a nuisance as well, especially if
> they launch kicad from a desktop UI.
>
> I'll check out the issue with the software rejecting ${ENV_VAR} in the
> file name editor.
>
> If we agree that a "../" style of relative path can only be interpreted
> as relative to the current project directory then I think that style of
> relative path may in fact be better in many ways than an absolute path
> (until a user moves the project directory). Some users prefer that
> style of relative path for their particular workflow so I can implement
> that if there are no objections.
>
> The other differences between the new resolver and the old system:
> a. a partial path like "path/to/my/file.wrl" will be interpreted as a
> path within the current working directory (new behavior) and if it
> doesn't exist there then it will be interpreted as a path within the
> ${KISYS3DMOD} directory (old behavior).
> b. due to the new behavior in (a), there is no need for "${KIPRJMOD}" -
> a partial path will always be checked against the current project directory.
>
> So a summary of the new resolver:
> a. env vars are not needed, but still supported (except for the issue
> mentioned in the filename editor)
> b. multiple model root paths are supported via aliases rather than env
> var; an aliased name appears to the user as
> "alias_name:my/partial/path/to/mymodel.wrl"; within the PCB file the
> alias itself appears as ":alias_name:my/partial/path/to/mymodel.wrl".
>
> - Cirilo
>
> On Tue, Apr 12, 2016 at 10:54 PM, Wayne Stambaugh > wrote:
>
> Hey Cirilo,
>
> Does the new 3D file path resolve no longer support environment variable
> expansion? If it doesn't, it should. We've have had so many issues
> with relative paths in the past that I'm reluctant to allow them.
> That's the primary reason we support environment variable expansion in
> the fp-lib-table and the old 3D file path code because it's infinitely
> more portable than relative and absolute paths. I know this is not the
> easiest issue to resolve but the best solution I've seen is how
> fp-lib-table handles them. If someone has any better ideas, I'm open to
> suggestion.
>
> Cheers,
>
> Wayne
>
> On 4/12/2016 2:18 AM, Cirilo Bernardo wrote:
> > Hi folks,
> >
> > The current behavior of the 3D filename resolver is to use
> > an absolute path in instances where a specified path is
> > not a descendant of a path within the aliased paths list
> > (that is, the filename cannot be shortened using an existing
> > alias). This decision was originally made to avoid ambiguous
> > relative paths such as "../../some/path" (what is it
> > relative to?). The obvious down side of course is that
> > absolute paths are not portable and this scheme would
> > be a nuisance to people who want to share their work
> > somehow. Since a number of people seem to be reliant
> > on using the "../" form of relative path to share their work,
> > I'd like to know people's opinions on using such relative
> > paths. If such relative paths are preferred to absolute
> > paths then I can make changes to the code such that
> > the resolver will assign a path relative to the Current
> > Project Directory rather than an absolute path in cases
> > where the file path cannot be shortened via the use of
> > an alias.
> >
> >
> > - Cirilo
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
>
> > Unsubscribe : https://launchpad.net/~kicad-dev
Re: [Kicad-developers] 3D file relative paths
Hi Wayne,
The new resolver will expand variable names; any path specified in a kicad
pcb file or footprint file will be interpreted in exactly the same way as
with the older system. The only difference with the new system is that
there is no need for environment variables (but they will be interpreted if
present). The idea was that users could use the GUI to specify the search
paths and give those paths names (aliases) which are analogous to the
environment variables, except that they aren't environment variables. I
think this is a Good Thing because fiddling with environment variables on
MSWin and OSX is a nuisance. I imagine some Linux users might find env vars
a nuisance as well, especially if they launch kicad from a desktop UI.
I'll check out the issue with the software rejecting ${ENV_VAR} in the
file name editor.
If we agree that a "../" style of relative path can only be interpreted as
relative to the current project directory then I think that style of
relative path may in fact be better in many ways than an absolute path
(until a user moves the project directory). Some users prefer that style
of relative path for their particular workflow so I can implement that if
there are no objections.
The other differences between the new resolver and the old system:
a. a partial path like "path/to/my/file.wrl" will be interpreted as a path
within the current working directory (new behavior) and if it doesn't exist
there then it will be interpreted as a path within the ${KISYS3DMOD}
directory (old behavior).
b. due to the new behavior in (a), there is no need for "${KIPRJMOD}" - a
partial path will always be checked against the current project directory.
So a summary of the new resolver:
a. env vars are not needed, but still supported (except for the issue
mentioned in the filename editor)
b. multiple model root paths are supported via aliases rather than env var;
an aliased name appears to the user as
"alias_name:my/partial/path/to/mymodel.wrl"; within the PCB file the alias
itself appears as ":alias_name:my/partial/path/to/mymodel.wrl".
- Cirilo
On Tue, Apr 12, 2016 at 10:54 PM, Wayne Stambaugh
wrote:
> Hey Cirilo,
>
> Does the new 3D file path resolve no longer support environment variable
> expansion? If it doesn't, it should. We've have had so many issues
> with relative paths in the past that I'm reluctant to allow them.
> That's the primary reason we support environment variable expansion in
> the fp-lib-table and the old 3D file path code because it's infinitely
> more portable than relative and absolute paths. I know this is not the
> easiest issue to resolve but the best solution I've seen is how
> fp-lib-table handles them. If someone has any better ideas, I'm open to
> suggestion.
>
> Cheers,
>
> Wayne
>
> On 4/12/2016 2:18 AM, Cirilo Bernardo wrote:
> > Hi folks,
> >
> > The current behavior of the 3D filename resolver is to use
> > an absolute path in instances where a specified path is
> > not a descendant of a path within the aliased paths list
> > (that is, the filename cannot be shortened using an existing
> > alias). This decision was originally made to avoid ambiguous
> > relative paths such as "../../some/path" (what is it
> > relative to?). The obvious down side of course is that
> > absolute paths are not portable and this scheme would
> > be a nuisance to people who want to share their work
> > somehow. Since a number of people seem to be reliant
> > on using the "../" form of relative path to share their work,
> > I'd like to know people's opinions on using such relative
> > paths. If such relative paths are preferred to absolute
> > paths then I can make changes to the code such that
> > the resolver will assign a path relative to the Current
> > Project Directory rather than an absolute path in cases
> > where the file path cannot be shortened via the use of
> > an alias.
> >
> >
> > - Cirilo
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
Hey Cirilo, Does the new 3D file path resolve no longer support environment variable expansion? If it doesn't, it should. We've have had so many issues with relative paths in the past that I'm reluctant to allow them. That's the primary reason we support environment variable expansion in the fp-lib-table and the old 3D file path code because it's infinitely more portable than relative and absolute paths. I know this is not the easiest issue to resolve but the best solution I've seen is how fp-lib-table handles them. If someone has any better ideas, I'm open to suggestion. Cheers, Wayne On 4/12/2016 2:18 AM, Cirilo Bernardo wrote: > Hi folks, > > The current behavior of the 3D filename resolver is to use > an absolute path in instances where a specified path is > not a descendant of a path within the aliased paths list > (that is, the filename cannot be shortened using an existing > alias). This decision was originally made to avoid ambiguous > relative paths such as "../../some/path" (what is it > relative to?). The obvious down side of course is that > absolute paths are not portable and this scheme would > be a nuisance to people who want to share their work > somehow. Since a number of people seem to be reliant > on using the "../" form of relative path to share their work, > I'd like to know people's opinions on using such relative > paths. If such relative paths are preferred to absolute > paths then I can make changes to the code such that > the resolver will assign a path relative to the Current > Project Directory rather than an absolute path in cases > where the file path cannot be shortened via the use of > an alias. > > > - Cirilo > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
Hi Cirilo, please consider to let users to use also $ENVAR with the new 3D refactor $ENVAR variables (ie.e KIPRJMOD) are still interpreted but cannot edited if you want to make a change to a model name still including i.e. KIPRJMOD, the pcbnew dialog will reject it, forcing the user to drop $ENVAR Error message: Invalid filename Maurice On 12/04/2016 08.18, Cirilo Bernardo wrote: Hi folks, The current behavior of the 3D filename resolver is to use an absolute path in instances where a specified path is not a descendant of a path within the aliased paths list (that is, the filename cannot be shortened using an existing alias). This decision was originally made to avoid ambiguous relative paths such as "../../some/path" (what is it relative to?). The obvious down side of course is that absolute paths are not portable and this scheme would be a nuisance to people who want to share their work somehow. Since a number of people seem to be reliant on using the "../" form of relative path to share their work, I'd like to know people's opinions on using such relative paths. If such relative paths are preferred to absolute paths then I can make changes to the code such that the resolver will assign a path relative to the Current Project Directory rather than an absolute path in cases where the file path cannot be shortened via the use of an alias. - Cirilo ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D file relative paths
On 12.04.2016 09:18, Cirilo Bernardo wrote: Hi folks, The current behavior of the 3D filename resolver is to use an absolute path in instances where a specified path is not a descendant of a path within the aliased paths list ... the resolver will assign a path relative to the Current Project Directory rather than an absolute path in cases where the file path cannot be shortened via the use of an alias. why relative to Current Project Directory and not to footprint directory? -- Regards, Sergey A. Borshchmailto: sb...@sourceforge.net SB ELDI ltd. Riga, Latvia ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
