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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
