kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I agree with your logic but there may be some user issues if you change
the packages3D install path.  Users who don't use the KISYS3DMOD
environment variable may loose the link to their 3D models.  You'll have
to look at the library path search code to see which paths are currently
supported before you make any changes.  Otherwise, you could have some
unhappy users.  Of course, you could modify the search path code to
include any new paths before changing the install path of packages3d.
This is a short term solution (think next stable release).  At some
point we should create some type of library table (similar to
fp-lib-table) support for 3D model libraries and schematic component
libraries.  Then we can remove the library search path code and all of
it's known issues from kicad (yeah!!!).

On 1/12/2015 2:15 AM, Adam Wolf wrote:
> I think this idea has merit.
> 
> If we are discussing large changes to the OS X paths, can I ask for
> another?  Let's move packages3d/ outside of modules/, so I can have
> users who download kicad-extras drag and drop a modules directory full
> of checked out github footprints into their ~/Documents/kicad/ (or
> whatever...) directory, without having to include packages3d/ in both
> the kicad and kicad-extras dmg.
> 
> Adam Wolf
> Cofounder and Engineer
> W&L
> 
> On Mon, Jan 12, 2015 at 12:56 AM, Collin Anderson
> <metacollin@xxxxxxxxxxxx <mailto:metacollin@xxxxxxxxxxxx>> wrote:
> 
>     Hi, I wanted to give some thoughts on the paths KiCad uses under OS
>     X, and some options to wrangle them all into something more unified
>     and easier to deal with in a non-breaking way.
> 
>     I'll get right to it:
> 
>     1. KiCad should never store, nor require, anything in /Library. 
>     This is a root-owned, non-user writable directory, including
>     /Library/Application Support, and is only used if absolutely
>     necessary.  It requires sudo or administrator privileges to create
>     and write to a kicad folder in /Library/Application Support.
>      /Library/Application Support is strictly for files that are to
>     remain invisible and are managed entirely automatically by a .app
>     bundle, and need to be shared between users on the system, but for
>     whatever reason cannot be stored in the .app bundle.  The Apple
>     developer documentation makes it clear that /Library and ~/Llibrary
>     must never contain files the user might need to interact with
>     directly, and these directories are intentionally hidden and OS X
>     actively discourages manual use of these directories, to the point
>     that they are completely invisible even if the Finder is set to show
>     invisible files.  KiCad should still look here, but the only reason
>     to create anything in /Library/Application Support is if an
>     administrator wants everyone to have certain custom assets, and
>     manually install them here.  They cannot be modified after that, and
>     should not be part of the normal KiCad install/usage mode. But files
>     the user will ever interact with must not be kept in either /Library
>     or ~/Library
> 
>     Source: https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html#//apple_ref/doc/uid/TP40010543-CH2-SW9 
>     (requires a free apple developer account sadly)
> 
>     2.  It's ok, and in fact, preferred, to store per-user copies of
>     updatable assets like a lot of what is in the kicad-library folder. 
>     This correctly integrates with features like Time Machine, File
>     Vault, and User Migration.  This may seem like a terrible waste of
>     space, but wasting space is how OS X likes to do things.  A lot of
>     design decisions have gone towards decoupling a lot of things that
>     could be shared by making copies (like all the dylibs and frameworks
>     in .app bundles, for example, making OS X apps balloon to...well,
>     Doc Brown would say 1.21 jiggabytes).  Looking in my own
>     ~/Library/Application Support folder, there are tons of things that
>     could be shared but aren't.  That, and if anyone did want to make a
>     change (which presumably is why they are stored in
>     ~/Library/Application Support to begin with, since if the files
>     don't need to be writeable, they are simply stored in the .app
>     bundle), they do not need administrator privileges.  Sure, I know
>     the rational is that the assets will automagically be updated using
>     git, and that's great, and you want to avoid doing this over and
>     over on a multiuser system.  BUT, what if something bad happens,
>     someone screws up and makes a bad commit that breaks someones
>     project? Or a crash our power outage dies and corrupts assets, but
>     there is no administrator around to clean up or do a git --reset
>     hard on /Library? If those assets are stored in the user's library
>     instead, that user can simply use Time Machine to return to an
>     earlier snapshot and in either scenario, they simply continue working. 
> 
>     Beyond that, maybe they just didn't want to update anything, and
>     someone else does :).  It's silly, but people do strange things.
> 
>     3. BUT, the ~/Library folder is, just like /Library, never to be
>     used for files the user will need to manage or interact with. Only
>     files created automatically and managed automatically by
>     applications are meant to reside here.  Given that the user may wish
>     to install or modify things in this folder, and at least for now has
>     to manually install things to it and can't do this form within the
>     KiCad app, there really should not be anything stored in ~/Library
>     either.  If an app does not ask the user specifically, the perferred
>     location for files a user may need to interact with is ~/Documents. 
>     This is why, for example, the Arduino IDE stores its libraries, and
>     allows custom cores and all sorts of things to override its default
>     settings (stored in the .app) by simply managing the
>     ~/Documents/Arduino folder.  It's acceptalbe, familiar, and OS X
>     user friendly to store customizable support files in their
>     ~/Documents folder.  It's the folder for stuff the user can mess
>     with, not just user-created stuff.  
> 
>     Anyway, I am not advocating the removal of any of the current search
>     paths, but rather adding ~/Documents/KiCad (let's use proper case
>     and make it look nice - KiCad vs kicad - while we're at it :)  ) and
>     give this path the highest precedence - the user should be able to
>     override whatever might be installed elsewhere with whatever they
>     put in this folder.  It would also be a nice place to store
>     documentation if it is auto updated in the future.  
> 
>     I have actually already made these changes in my, uh, personal
>     version of KiCad, and would be happy to put them in a branch, but I
>     didn't want to just shove all this in a merge request, since its a
>     pretty big change to, well, policy on OS X.  I am a newcommer, and
>     its totally possible I missed something and there are very good
>     reasons for how things are done now, and beyond that, maybe no one
>     else wants to do any of this, has a better idea, or doesn't like
>     this one.  Which is fine.  These are just suggestions coming from a
>     long time mac user, and if any of this is something the other devs
>     would like to look into, I'll put up the branch (it also changes
>     comments and documentation to reflect the path changes - I did it a
>     while ago then realized how big of a change I was doing and sort of
>     put it on the back burner).
> 
>     If this is not something anyone is interested in, I completely
>     understand and I will not mention or press for it again.  Please
>     don't think I am trying to to tell anyone here what to do - I defer
>     to the judgement of all the people who actually wrote those 500,000+
>     lines of code, of course :).  Sorry about the length again.  I am
>     very bad at being concise :(.
> 
>     -- 
>     "Violence is the last refuge of the incompetent." - Isaac Asimov
> 
> 
>     _______________________________________________
>     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
>