Re: Removing the Filename flag in Doc. based Application
Re: Removing the Filename flag in Doc. based Application
- Subject: Re: Removing the Filename flag in Doc. based Application
- From: "Kyle Sluder" <email@hidden>
- Date: Sat, 24 May 2008 00:52:45 -0400
On Fri, May 23, 2008 at 11:06 PM, Roland King <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden