kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

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>
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
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>