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