Adam, You deserve to throw yourself a party given all the OSX work you have been doing. I sure would like to join you but you are little too far away from southeastern Virginia for me to make that party. I have to agree with Jean-Paul, Minneapolis is a little too cold for my blood.
Cheers, Wayne On 1/12/2015 10:22 AM, Jean-Paul Louis wrote: > Minneapolis? > Not a chance. I left Granger, IN for a while because it was too cold. I am > vacationing in Wilmington, NC where temperature is 65F. > > I will think about a party in Minneapolis maybe in July, LOL. > > Adam, > Thanks for your great work for us, poor OS X users. > > Jean-Paul > AC9GH > > >> On Jan 12, 2015, at 9:49 AM, Adam Wolf <[email protected]> wrote: >> >> Hi Wayne, >> >> I am taking this as temporary preapproval for a packages3d change. I will >> have a patch this week for your approval and hopefully by then the rest of >> the OS X devs have discussed the Documents search path change, so we can get >> nightlies out! >> >> I think I may literally throw a party when I get OS X nightlies pushed. >> Anyone else near Minneapolis MN? :) >> >> Adam Wolf >> Cofounder and Engineer >> Wayne and Layne >> >> On Jan 12, 2015 8:45 AM, "Wayne Stambaugh" <[email protected]> wrote: >> 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 >>> <[email protected] <mailto:[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] >>> <mailto:[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 >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
