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
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-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
