3 ms·
While absurdly long, that path actually does (mostly) make sense. If you were to do it, it would be an organizational mess when looking for something. /Develop
by Zev 17y ago
While absurdly long, that path actually does (mostly) make sense. If you were to do it, it would be an organizational mess when looking for something.
/Developer is the standard install path. Documentation/ for docs, DocSets for the actual docs (as opposed to sample code), com.apple.ADC_Reference_library to say its an ADC reference library (as opposed to installing your own docsets, which some libraries have), CoreReference.docset to say which docset it is exactly (leopard vs snow leopard, for example), Contents/ is pretty standard for OS X bundles, Resources/ since docs are technically resources, Documents/ (again, there are other files here: sample code, tech notes, etc), documentation/ for the documents themselves, Cocoa/ for which framework you're looking at (It could also be Carbon, Webkit's CSS, Darwin, Java, etc), and, well, thats the end of the chain on my system. But to continue it based on a guess, Reference/, possibly redundant, but its nice for organizational purposes, ApplicationKit/ - you are looking up something in AppKit, but there are other *Kit's that can be used as well, Classes/ instead of headers, maybe, and then NSApplication_Class for the class that you want.
- makecheck 17y agoThe structure is consistent with other bundles. But the question is, are bundles really the logical way to handle documentation? I don't think so. If you look in places like "/Library/Application Support", everything is basically broken down by product or vendor. It is hard to imagine having so much documentation installed that similar naming wouldn't suffice for DocSets. Apple has also used saner documentation layouts elsewhere (and oddly, in places that are probably not meant to be "public" documentation). For instance, there's a /Library/Documentation, and its layout is very easy to follow.