kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <adamwolf@xxxxxxxxxxxxxxxxxxxx> 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" <stambaughw@xxxxxxxxx> 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
>>> <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
>>>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>     Unsubscribe : https://launchpad.net/~kicad-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
>>>
>>
>>
>> _______________________________________________
>> 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
>> _______________________________________________
>> 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
>