kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Hi Cirilo,

This patch should just change the default packages3d (for new users who
don't have preferences saved) to match what we're currently shipping.

I will definitely look at your branch once 4.0.0 is released :)

Adam Wolf

On Wed, Nov 18, 2015, 5:44 PM Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>
wrote:

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