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 <stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
