On Thu, Nov 19, 2015 at 7:57 AM, Adam Wolf <adamw...@feelslikeburning.com> 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
_______________________________________________ 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
