On Fri, May 23, 2008 at 11:06 PM, Roland King <[EMAIL PROTECTED]> wrote: > This seemed to me to be a good example of what's being discussed in the 'how > hard is Cocoa to learn' thread and is the kind of thing makes me pull my > hair out.
To be fair, I think this the necessary foundation is pretty well laid-out in the "Roles of Key Objects in Document-Based Applications" section of the Document-Based Applications Overview guide: http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Concepts/RolesOfDocObjects.html#//apple_ref/doc/uid/20000025 Yes, this means learning about some classes, like NSDocument and NSWindowController. It means knowing that the skeleton NSDocument subclass which Xcode generates takes a shortcut by implementing -windowNibName instead of -makeWindowControllers, but this is mentioned in the documentation, which goes on to enumerate the changes you must make in your NIB if you decide to override -makeWindowControllers instead. > If you hook things up with IB and write code you think it's quite simple, > then you come to something like wanting to change the title of the document > window and .. in order to do it you need to understand the way the framework > makes NSWindowControllers, how that relates to the NIB you want for the > document, that the NSWindowController has a method > synchronizeWindowTitleWithDocumentName which needs to be overridden and that > you then have to override the document method which makes the window > controllers to make one of yours. So in other words, you must read the documentation. But I completely understand how this can be insufficient. I'm really torn on this debate; it seems to me like there are two sides to the "insufficient documentation" argument: a lot of people decrying the docs simply don't read (enough of) them, but a lot do and still don't understand. At the risk of offending some new developers, AppKit is not Windows Forms or Swing or GTK or any other object-oriented windowing system you've used before. Yes, your experience with object-oriented programming will certainly help you, but I don't care if you're Donald Knuth, you still *must* start from scratch when you begin learning Cocoa. > phew - it all makes sense, and Kyle that was a great explanation, but I have > no idea if I'd have gotten there. I'm glad you think I explained it well. Personally I don't know when I reached the point where I could extract this kind of meaning (i.e. understand), but it wasn't that long ago. I do not claim to be a Cocoa expert. I am very far from it; I am still learning. > What I find with the Cocoa framework is that I know there must be a *right* > way to do anything because I know the framework is well-designed and has > been refined over the course of years, I know there's some perfect place in > a responder chain to put that one method, or there's one method I can > override which is in the exact place to tweak the behaviour I want. Finding > that place instead of putting in a kludge suddenly requires 20x the depth of > understanding of the entire framework. I suspect a number of people, unable > to find the right place, end up sticking code in the wrong place. This is why I'm afraid of the Cocoa Text System. But what I've gained from my development with Cocoa so far is the exact insight you mention: you can get by with only so much knowledge, but there are times where your conceptual understanding must grow by leaps and bounds before you can move further. And there have been times where the documentation only goes so far. That's when I look at /Developer/Examples for further insight. But the most important thing I have learned is that simply forging ahead will lead to agony and frustration. Instead, you must consume all available resources, which sometimes means hopping on #cooca-dev and pestering the hell out of everyone with questions that I know are basic to anyone familiar with that aspect of the framework, but the answers to which will open doors to comprehension. > I'm still reading copious amounts of cocoa documentation trying to form my > mental model of what happens and when it happens and the lifecycle of > applications, exactly what methods things pass through on the way, how > different types of message pass down the responder chain and thus where > might be a good place to look for a likely hook to do the thing I want to > do. I can imagine a series of diagrams each showing a timeline of calls for > one type of operation, eg opening the first window, processing a double > click, opening a menu etc., currently I can just imagine the diagrams, I > can't fill in the boxes. This is good, although I tend to think more of an actor mentality than a timeline. That is, NSApp handles incoming WindowServer events which then hands them off to the appropriate NSWindow which then hands them off to the appropriate view... Yes, I understand that without an arrow of time my mental model doesn't make sense anyway, but I think that defining the model in terms of individual objects really accentuates the way that Cocoa apps actually operate. Decisions like the responder chain are often made by individual objects, depending on their current state, querying their delegate, and other such local information. > I think this is why it takes time and effort to learn cocoa, and why people > are surprised after they hook up their first application and it works .. > then one day they want to do what seems trivial and hit the brick wall which > requires going back to the beginning and gaining the full understanding of > what the framework is doing. Nobody said it was easy, but it sure is fun. Once you expend the bit of frustration that comes with stopped progress, it is a very nice feeling to have that knowledge under your belt. > .. and don't get me started on bindings :) Ugh. Bindings themselves are not hard to understand or even implement (they're just KVO, after all), but every so often I'll be using them and then just get stopped in my tracks. I don't know what it is about them. Sorry to hijack your thread, Vince. Hope I've helped you out. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
