kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Thu, Nov 19, 2015 at 7:57 AM, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>
wrote:

> Hi folks,
>
> I'm trying to wrap up all the OS X packaging related bugs ASAP before
> 4.0.0 drops shortly.  I got a nasty one where we weren't actually
> supporting 10.8, but as of this morning I fixed that! (It wasn't a KiCad
> code change.)
>
> However!
>
> For OS X, we put packages3d next to modules, rather than inside of it.  I
> think we had a pretty long discussion on this before, but basically OS X
> users are trained to use installers where they drag and drop directories
> into destination directories.  We have a Kicad Extras dmg where we put the
> offline footprints and other "extras", and if we put the packages3d inside
> of the stock modules/ directory, when they drag and drop the extras ones
> into the directory, it'll clobber them, so we store them parallel.  I kinda
> mangled the explanation there, so if someone wants clarification, I can
> write one up.
>
> A user reported that the default packages3d path doesn't match what we
> package for OS X. (https://bugs.launchpad.net/kicad/+bug/1496214)
>
> I wrote a small patch to fix this, and it appears to work.  The changes
> are gated for OS X, but I'd appreciate another eye on this.
>
> Thoughts?
>
> Adam Wolf
> Cofounder and Engineer
> W&L
>

3D paths are a royal pain in the ass at the moment.  All I can suggest for
the stable release is a
"#ifdef APPLE" to use a different default path. I've argued before that the
3D models should be
split off entirely or at the very least should not be within the 'modules'
subdirectory but I've always
been a minority. :)

I encounter these path problems on my local install as well - it's just an
expected effect of the
rigid legacy model selection code. The filename resolver in my 3D refactor
branch is meant to fix
that, so if you have the time and would like to comment on what will
hopefully become a future
feature you could build my branch and see if the resolver helps out. The 3D
filename resolver
stores a list of relative path bases in a text configuration file in the
per-user kicad config directory
(for example .config/kicad/3d/3Dresolver.cfg on my system) and magically
includes the current
project path in the list of relative path bases. Some side effects of the
resolver are (1) you no
longer get a "XXX path does not exist" error - unfortunately you just get a
blank 3D render instead
but that should be enough of a clue that you need to set up the filename
resolver - once you set a
relative path base to point to the actual location of 'packages3d'
everything magically works.
Of course we probably still need an "#ifdef APPLE" to set a sensible
default to begin with.
(2) that "do you want to use a relative path?" dialog disappears - sorry,
no choice - if your model
is within a configured relative path base it's going to be recorded as a
relative path. Sure there are
disadvantages to using a relative path, but I think for our majority of use
cases the good points far
outweigh the disadvantages and advantages of specifying absolute paths. An
absolute path will
still be recorded if the path bases are not a component of the path. (3)
Users can point to
multiple base paths so they don't have to worry about being careful with
merging their collections
with the kicad  models; at the moment users can do that by defining
multiple environment
variables and hand-editing paths to contain something like
${PATH1}/modelA.wrl, ${PATH2} .. etc
but that's obviously a horrible way to do things.

- Cirilo