> On Oct 10, 2014, at 3:13 PM, Bernhard Stegmaier <[email protected]> > wrote: > > I noticed the caching problem about 1 year ago when I played around with the > retina setting in the Info.plist for KiCad. > I had built KiCad and launched it => non retina settings (OK, was not > correctly configured). > I changed the setting in Info.plist directly in the bundle and it nearly > drove me mad because it just didn’t change anything. > I then discovered that if I just copy/move the bundle to a new place then > suddenly the new settings got recognized. > When I changed things in KiCad source, removed the bundle and built new it > also worked. > > At least for icons Apple docs tell the following > https://developer.apple.com/library/mac/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html > <<< > Launch Services maintains a central data structure, the Launch Services > database, in which it records all of the pertinent information about > applications and the kinds of document files and URLs they are capable of > opening. Whenever a new application becomes known to the system (such as when > the user drags it from an installation disk into the Applications folder), > the application is registered with Launch Services, which copies the needed > information about the application into its database. > I don’t know if you can somehow check what’s in this DB...
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -h > On my machine currently when double clicking KiCad files the old version > living in /Applications gets started - even though I haven’t used this > version for weeks now and I have run the new versions from my build folder > more than once... > > > Regards, > Bernhard > >>> On 10.10.2014, at 23:53, Andy Peters <[email protected]> wrote: >>> >>> On Oct 10, 2014, at 2:34 PM, Bernhard Stegmaier <[email protected]> >>> wrote: >>> >>> Well, it might seem so but that’s IMHO not the whole story. >>> >>> From an OSX perspective there currently is not “some apps”, it is just >>> *one* application, the kicad launcher. >>> Having the other (command-line) applications in the bundle is just a >>> workaround and OSX doesn’t know anything about them from an application >>> view. >>> For this single application only one file extension with one icon is >>> registered. >>> On a clean machine I bet you won’t see more than an icon for .pro files. >>> >>> If you see other icons for pcbnew, etc. file types at all then I guess this >>> is just because you still have/had other versions on your machine (on my >>> machine all icons are still correct, but I guess that’s only because I have >>> an old version still installed). Further, OSX is obviously caching many >>> things… so, often you might see still old things (try to edit Info.plist an >>> application… for me this works reliably with the new content only when >>> deleting the old application, renaming, or copying/moving it around). >> >> What Bernhard is saying here is interesting. I regularly build Kicad on two >> machines -- my MacBook Pro and my iMac. Both run the same version of OS X >> and both have the same version of Xcode. Now I _think_ I've got the >> dependencies the same -- I believe this because Kicad builds completely on >> both. >> >> Now on the MacBook Pro I see the expected icon for just kicad.app (the >> project manager) and only for Project.pro files. For the other Kicad >> applications (eeschema, pcbnew) both the applications themselves and the >> associated files have the default "sheet" icon. >> >> BUT ... on the iMac, with the same BZR (5173) version and all of that, I see >> all of the applications have their individual icons and the design files >> have the respective icons, too. >> >> I just did a "make clean" and cmake and all of that on the iMac; when it's >> done I'll see what happened. >> >>> >>> However, I am working on getting back shortcuts for the individual >>> applications without duplicating all the libs and kifaces. >>> With that, all icons should be right again. >>> But, there is some more work to do to get it right when launching pcbnew >>> individually or from launcher (e.g., config file locations which are >>> currently dependent on binary/app name). >>> Those things were broken before, too... >> >> >> I think the main (only?) use case for running pcbnew or eeschema separately >> (not launched from the Kicad project manager) is so you can get into the >> library editors. But yeah, if you're going to have separate applications for >> each, they should have proper icons and so too should the associated files. >> Otherwise, the users will just be confused. >> >> -a >> _______________________________________________ >> 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
