File's Owner

  • I decided to once again go verbatim through Cocoa Fundamentals. So far
    it has been largely "uh-huh, yep", but the File's Owner, my nemesis,
    comes up again.

    http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CommunicatingWithObjects/chapter_6_section_3.html


    > You connect an outlet in Interface Builder, but the procedure starts
    > in Xcode. The following steps describe the procedure:
    >
    > When defining your custom class, declare an outlet by tagging the
    > instance variable with the IBAction qualifier.
    > In Interface Builder, drag a generic object into the top level of
    > the nib file window (if one doesn’t already exist for your custom
    > class).
    > If an instance of your custom class is to be the File’s Owner for
    > the nib file, this step is not necessary. Also, if you’re defining a
    > custom NSView object, select that object instead.
    >
    > Import the custom class into Interface Builder.
    > With the generic object (or File’s Owner) selected, type the name of
    > your custom class in the Class field of the Identify pane of the
    > Interface Builder inspector. This assigns your custom class as the
    > class of the selected object. This step has to be done only once.
    >
    > Select your custom instance (or File’s Owner).
    > Right-click or Control-click this object to display the connections
    > panel.
    > Find your outlet under Outlets and drag a connection line from the
    > circle next to the outlet to the object on the user interface that
    > you want that outlet to reference.

    I sent feedback on this as File's Owner is mentioned several times and
    not defined. There seems to be some huge problem with File's Owner.
    Even Aaron Hillegass says that people have trouble understanding
    File's Owner - and sure enough, when I read his explanation, I
    remained clueless.

    I can follow making a generic NSObject set to my custom class, but why
    File's Owner?

    My birthday is coming up and if I can understand File's Owner, I will
    consider that one of the best presents.

    As usual, I can recite the documentation without understanding it :
    File's Owner is a proxy object that is set at nib load time to the
    object that loaded the nib (I don't know what object loaded my nib, so
    that does not help me). In MainMenu.nib, this is the application
    instance, which is a shared singleton instance of NSApplication (how
    all applications can share this is beyond me), which is also set to
    the global variable NSApp (uhh, OK...).

    That's all well and good, but what exactly is this thing? Why would I
    succeed in having an outlet in my class if I set the Class Identity of
    File's Owner to my custom class? Why should I set File's Owner's Class
    Identity rather than the Class Identity of a plain NSObject that I
    drag out of the Library in IB?
  • I'm trying to figure out why the big hang up on needing to understand
    it fully. Not understanding it should not prevent you from developing
    applications. So why the hangup? What is the actual problem? Just set
    your own NSObject based app delegate as the File's Owner delegate in
    IB and start adding your code to it. That's really all you *need* to
    know.

    -Matt

    --------------------------
    Matt Long
    <matt.long...>
    http://www.matthew-long.com/

    On May 23, 2008, at 12:49 PM, Johnny Lundy <johnnylundy...> wrote:

    > I decided to once again go verbatim through Cocoa Fundamentals. So
    > far it has been largely "uh-huh, yep", but the File's Owner, my
    > nemesis, comes up again.
    >
    > http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CommunicatingWithObjects/chapter_6_section_3.html

    >
    >> You connect an outlet in Interface Builder, but the procedure
    >> starts in Xcode. The following steps describe the procedure:
    >>
    >> When defining your custom class, declare an outlet by tagging the
    >> instance variable with the IBAction qualifier.
    >> In Interface Builder, drag a generic object into the top level of
    >> the nib file window (if one doesn?ft already exist for your custom
    >> class).
    >> If an instance of your custom class is to be the File?fs Owner for
    >> the nib file, this step is not necessary. Also, if you?fre defining
    >> a custom NSView object, select that object instead.
    >>
    >> Import the custom class into Interface Builder.
    >> With the generic object (or File?fs Owner) selected, type the name
    >> of your custom class in the Class field of the Identify pane of th
    >> e Interface Builder inspector. This assigns your custom class as t
    >> he class of the selected object. This step has to be done only once.
    >>
    >> Select your custom instance (or File?fs Owner).
    >> Right-click or Control-click this object to display the connections
    >> panel.
    >> Find your outlet under Outlets and drag a connection line from the
    >> circle next to the outlet to the object on the user interface that
    >> you want that outlet to reference.
    >
    > I sent feedback on this as File's Owner is mentioned several times
    > and not defined. There seems to be some huge problem with File's
    > Owner. Even Aaron Hillegass says that people have trouble
    > understanding File's Owner - and sure enough, when I read his
    > explanation, I remained clueless.
    >
    > I can follow making a generic NSObject set to my custom class, but
    > why File's Owner?
    >
    > My birthday is coming up and if I can understand File's Owner, I
    > will consider that one of the best presents.
    >
    > As usual, I can recite the documentation without understanding it :
    > File's Owner is a proxy object that is set at nib load time to the
    > object that loaded the nib (I don't know what object loaded my nib,
    > so that does not help me). In MainMenu.nib, this is the application
    > instance, which is a shared singleton instance of NSApplication (how
    > all applications can share this is beyond me), which is also set to
    > the global variable NSApp (uhh, OK...).
    >
    > That's all well and good, but what exactly is this thing? Why would
    > I succeed in having an outlet in my class if I set the Class
    > Identity of File's Owner to my custom class? Why should I set File's
    > Owner's Class Identity rather than the Class Identity of a plain
    > NSObject that I drag out of the Library
  • What programming experience do you have?  Perhaps I can explain File's Owner in terms of some other framework you already know ?
      You use the File’s Owner “proxy” in each nib file to enable connections or key paths to objects that are not instantiated within that nib file.  Interface Builder needs an icon for you to drag such connections to and from.  File’s Owner is just such an icon.  First Responder is another such Icon.  Any connections or key paths that involve the File’s Owner icon will be established with whatever object is specified as the “owner” when the nib file is loaded via + loadNibNamed:owner:.  The MainMenu.nib file is loaded automatically by the framework by calling code similar to [NSBundle loadNibNamed:@”MainMenu” owner:NSApp];  Does that line of code mean anything to you ?
      Nib files can be loaded at any time while an application is running, and the same nib file can be loaded multiple times creating new copies of all objects within the nib each time.  Can you see how it is useful to be able to make connections to objects that are not instantiated within the same nib file ?  Consider how NSDocument loads nib files that define the objects representing each document instance.
      @implementation MYDocument : NSDocument
      {
        IBOutlet NSTextField  *someTextFiledInMyAssocoatedNibFile;
      }

      - (NSString *)windowNibName
      {
        Return @”MYNibFile”;
      }
      @end

      At some point, you will create a MyDocument instance and as part of its initialization it will execute a line of code like the following:
      [NSBundle loadNibNamed:[self windowNibName] owner:self];
      Because the MYDocument instance is the owner specified when the nib is loaded, any connection made within the nib to the someTextFiledInMyAssocoatedNibFile outlet will be connected to the instance of MYDocument that loaded the nib file.
      When you open a second document, it will also call [NSBundle loadNibNamed:[self windowNibName] owner:self]; except the “self” refers to the second instance of MYDocument.  Loading the nib file twice creates two copies of every object within the nib file, but the connections made to File’s Owner within the nib file are established to the two different instances of MYDocument.

      P.S.
      You say "I don't know what object loaded my nib, so that does not help me" and then immediately quote the documentation which says "In MainMenu.nib, this is the application instance, which is a shared singleton instance of NSApplication which is also set to the global variable NSApp."  The documentation explicitly  tells you that in the case of the MianMenu.nib file, the File’s Owner is a proxy for an instance of the NSApplication class.
      You then say "how all applications can share this is beyond me".  This indicates to me that you don't know what a Singleton is and don’t know what a Proxy is and don't know what a global variable is and don't know that with Unix (e.g. Mac OS X) applications do not generally share global variables.
      It's no wonder you are struggling with Cocoa.  You are apparently not a C programmer, not aware of common object oriented patterns like the Singleton, and not familiar with Unix.  In my opinion, C programming, pattern awareness, and basic operating system familiarity are all prerequisites to learning Cocoa.
  • On May 23, 2008, at 1:49 PM, Johnny Lundy wrote:

    > As usual, I can recite the documentation without understanding it :
    > File's Owner is a proxy object that is set at nib load time to the
    > object that loaded the nib (I don't know what object loaded my nib,
    > so that does not help me).

    You should know that.  Either it's the MainMenu.nib, which is
    automatically loaded by the application object (an instance of
    NSApplication, by default) or you've made explicit other
    arrangements.  If you've got a nib other than MainMenu.nib, how are
    you arranging for it to be loaded?  Whatever the answer to that
    question, it tells you what object will be the File's Owner.

    > In MainMenu.nib, this is the application instance, which is a shared
    > singleton instance of NSApplication (how all applications can share
    > this is beyond me),

    It's not a singleton across all processes.  That's not the meaning of
    singleton.  A singleton is usually singular only in the context of a
    single process.  Basically, the process which is your running
    application contains one single instance of NSApplication or an
    NSApplication-derived class.  This object is the File's Owner of
    MainMenu.nib.

    > which is also set to the global variable NSApp (uhh, OK...).

    A pointer to that object, the single instance of NSApplication or a
    subclass, is stored in a global variable, NSApp.  (Again, just to
    avoid confusion, "global" within your process, not across all
    processes.)

    > That's all well and good, but what exactly is this thing? Why would
    > I succeed in having an outlet in my class if I set the Class
    > Identity of File's Owner to my custom class?

    A nib is a collection of interrelated objects freeze-dried into a
    file.  When you load a nib, you reconstitute the objects within it and
    reestablish the connections between them.  However, this object graph
    would be disconnected from the other objects that already exist within
    your application, and so would have very restricted ability to
    interact with them.  You want a way to connect up the two object graphs.

    So, in your design of your application, you pick some object that
    exists prior to the nib being loaded as the connection point -- the
    place where the new objects-to-be-loaded will connect up with your
    existing objects.  Which of your objects you pick is up to you,
    although it is often convenient to use an instance of a custom
    subclass of NSWindowController or NSViewController.

    The nib has a placeholder in the freeze-dried object graph.  This is
    like a blank spot on a diagram, where arrows point to it, but there's
    nothing there, yet.  There can also be arrows pointing out from this
    blank spot to the other things in the diagram.  When your code decides
    it's time to load the nib, you specify in that code that the object
    you picked in the previous paragraph will be the nib's owner.  The nib
    loading machinery plops the owner object into the blank spot in the
    diagram.  It already has existing connections to your object graph and
    now, as part of nib loading, the arrows to and from that blank spot
    are connected to and from that owner object.  Objects in your nib
    which had references to the file's owner get references to that
    object.  Where there were arrows pointing out from the blank spot,
    those are outlets from your file's owner.  The nib loading machinery
    sets the outlets on your owner object to point to the newly-created
    objects from the nib.

    Now your object graph is integrated, where the new objects have the
    references to pre-existing objects which they need to access, and at
    least one of the pre-existing objects has a way of addressing the new
    objects.

    The nib needs to be told the class of your (future) file's owner so
    that it can know what outlets it supports.  It figures this out by
    parsing the .h file which declares that class, looking for the
    IBOutlet keyword.  You want to set up outlets so that the owner object
    has references to the objects that were created by loading the nib.

    > Why should I set File's Owner's Class Identity rather than the Class
    > Identity of a plain NSObject that I drag out of the Library in IB?

    Because that NSObject would not have any relationship to your pre-
    existing object graph.  There are sometimes good reasons to drag an
    NSObject out of the library to instantiate it in the nib, and set its
    class to one of your own, and then hook it up to the other objects in
    your nib.  It's just that this serves a different purpose than File's
    Owner.

    I hope that helps.

    Cheers,
    Ken
  • On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:

    > I decided to once again go verbatim through Cocoa Fundamentals. So
    > far it has been largely "uh-huh, yep", but the File's Owner, my
    > nemesis, comes up again.

    File's Owner is a title. It is similar, in a way, to the title:
    President of the United States. Every four years Americans elect the
    POTUS. The individual who is POTUS changes, the title remains the same.

    Software development, in this case Cocoa, is not a democracy. You, the
    developer, are absolute dictator of your code. You, the developer,
    have the absolute power, and in fact the responsibility, to choose the
    object that is the File's Owner for each nib in your application.

    Why must you do this? What is the point of this title of File's Owner?

    Consider the nibs in your application. They contain a description of a
    UI with some number of views and other objects. When a nib is loaded
    into your application this description is turned into a view hierarchy
    of real objects, usually rooted in a NSWindow.

    How can this newly created View hierarchy communicate with the rest of
    the application, and visa versa? The answer is outlets. Where are the
    outlets? In the File's Owner.

    The object that has the outlets that are assigned to when the  nib is
    loaded can be of any kind. That's why the documentation calls File's
    Owner a proxy. It's also why you must tell IB the Class of the File's
    Owner for a given nib.  The File's Owner icon in the IB window is
    there so you can set the outlets and actions of it so that you can
    make the connections between the new objects in the nib and the
    already existing objects in the application. It's a representation, or
    a title, of the real object that owns the nib.

    --
    Brian Stern
    <brians99...>
  • On Fri, May 23, 2008 at 11:49 AM, Johnny Lundy <johnnylundy...> wrote:

    > I sent feedback on this as File's Owner is mentioned several times and not
    > defined. There seems to be some huge problem with File's Owner. Even Aaron
    > Hillegass says that people have trouble understanding File's Owner - and
    > sure enough, when I read his explanation, I remained clueless.

    So ask some questions (personally without all the banter and unneeded tone).

    > I can follow making a generic NSObject set to my custom class, but why
    > File's Owner?

    You do this so Interface Builder knows what class the owner of the nib
    will be so it can expose the correct outlets and actions when you
    attempt to make connections to/from the file's owner proxy object with
    other objects in the nib.

    > That's all well and good, but what exactly is this thing?

    It is a proxy object that allows objects instantiated in the nib to be
    connected with an object outside of the nib, in this case the object
    that has been specified as the owner of the nib when it was loaded.

    So the real question you likely have is who is loading my nib? We can
    only help answer that if you outline more about the nib and the code
    involved. However as a guess I assume you are talking about
    MainMenu.nib (default name for the "NSMainNibFile" entry that you
    specify in your Info.plist). This nib is loaded by the NSApplication
    instance the represents your Cocoa application (created when you call
    NSApplicationMain() in you main entry point). NSApplication is the
    owner of that nib, hence the file's owner proxy object represents it.

    > Why would I succeed in having an outlet in my class if I set the Class Identity of
    > File's Owner to my custom class?

    Please restate since I don't follow the question.

    > Why should I set File's Owner's Class
    > Identity rather than the Class Identity of a plain NSObject that I drag out
    > of the Library in IB?

    See my first answer.

    -Shawn
  • On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
    > I decided to once again go verbatim through Cocoa Fundamentals. So
    > far it has been largely "uh-huh, yep", but the File's Owner, my
    > nemesis, comes up again.

    I tried to answer your File's Owner and NSApp questions last week
    (copied below).  If you can indicate at what point in my explanations
    you start getting lost, I can try to explain better.

    Again, I'm sensing a very fundamental disconnect, perhaps more
    fundamental than you realize.  Anybody can recite documentation, so
    there's no need to tell us that and no need to recite the
    documentation.  I think it would be more helpful to tell us at what
    *part* of the documentation you start to get lost, and what
    specifically is confusing about it, perhaps as relates to your other
    programming experience.  If the answer is that you draw a complete
    blank, then we shouldn't be addressing that issue at all; you need to
    step back to a more fundamental level and see if you feel fluent at
    that level.

    --Andy

    Here's my reply from last week:

    On May 15, 2008, at 11:11 AM, Andy Lee wrote:

    > On May 14, 2008, at 10:33 PM, Johnny Lundy wrote:
    >> So it's the application instance. I don't understand what the
    >> application instance is. I can recite the documentation, which says
    >> it is a shared instance of NSApplication, also known as NSApp which
    >> is a global variable, none of which help me.
    >
    > To me this indicates a very fundamental disconnect, because what you
    > recited explains NSApp perfectly.  I can't tell where the disconnect
    > is, so I'll try to spell this out quickly.  No offense intended here
    > -- I honestly don't know where the disconnect is.
    >
    > You are writing a Cocoa application.  There is a class called
    > NSApplication that represents the concept of a Cocoa application.
    > That's the purpose of a class in an object-oriented language, to
    > describe a *class* of things conceptually.  Classes are usually
    > named for the thing they describe -- hence "NSApplication".
    > NSApplication handles the generic things that Cocoa applications do:
    > managing the main menu, managing the window list, dealing with mouse
    > and keyboard events, and so on.
    >
    > Cocoa applications create objects (instances of classes).  That's
    > what they do all day.  Objects get created, they send messages to
    > each other, they get dealloc'ed.  Thousands and thousands of
    > objects, all day long.  In your application there is one special
    > object that is an instance of NSApplication.  It represents the
    > application itself.  I repeat: there is an object in your
    > application that represents the running application itself.  There
    > is only one such object, and it is stored in a global variable
    > called NSApp.  That is what "application instance" means.
    >
    >> Why would someone bind to File's Owner? What specifically is it?
    >
    > Unlike most other objects in a nib file (First Responder being the
    > exception), File's Owner is not a specific object.  It is a
    > placeholder for an "owner" object that will be specified when the
    > nib file is loaded.  You edit a nib file knowing that it will be
    > loaded at some point in your program, and *at that future time* the
    > owner of the file (hence "File's Owner") will be specified.
    >
    > The file's owner gives your program access to the objects in the nib
    > file, through the connections you made to it in the nib.
    >
    > I think newcomers sometimes assume that when you load a nib you get
    > some sort of NibObject that you can query to get at the objects in
    > the nib, perhaps using the name you assigned in the nib file.  This
    > is an understandable assumption, but you don't get any such object.
    > You need to specify a file's owner for the nib (using the second
    > argument to +loadNibNamed:owner:), and you need to have constructed
    > the nib so it connects the file's owner to at least one of its
    > objects.
    >
    > --Andy
  • On Fri, May 23, 2008 at 1:27 PM, Shawn Erickson <shawnce...> wrote:
    > On Fri, May 23, 2008 at 11:49 AM, Johnny Lundy <johnnylundy...> wrote:

    >> I can follow making a generic NSObject set to my custom class, but why
    >> File's Owner?
    >
    > You do this so Interface Builder knows what class the owner of the nib
    > will be so it can expose the correct outlets and actions when you
    > attempt to make connections to/from the file's owner proxy object with
    > other objects in the nib.

    To be a little clearer the above is only at play when you are editing
    with your nib using Interface Builder. The class you specific in
    Interface Builder for the file's owner isn't a factor at runtime.

    >> That's all well and good, but what exactly is this thing?
    >
    > It is a proxy object that allows objects instantiated in the nib to be
    > connected with an object outside of the nib, in this case the object
    > that has been specified as the owner of the nib when it was loaded.

    Again this aspect is only a factor at runtime. The file's owner that
    you see when editing a nib file is simply a graphical representation
    of the object that will own the nib when the nib is loaded by your
    application. It provides a way to make connections to objects in the
    nib using control dragging and like.

    -Shawn
  • On Fri, May 23, 2008 at 1:27 PM, Shawn Erickson <shawnce...> wrote:

    > So the real question you likely have is who is loading my nib? We can
    > only help answer that if you outline more about the nib and the code
    > involved. However as a guess I assume you are talking about
    > MainMenu.nib (default name for the "NSMainNibFile" entry that you
    > specify in your Info.plist). This nib is loaded by the NSApplication
    > instance the represents your Cocoa application (created when you call
    > NSApplicationMain() in you main entry point). NSApplication is the
    > owner of that nib, hence the file's owner proxy object represents it.

    Oops I intended to reference the following in my first post...

    <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /AddingBehaviortoaCocoaProgram/chapter_4_section_2.html#//apple_ref/doc/uid
    /TP40002974-CH5-DontLinkElementID_1
    >

    <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CoreAppArchitecture/chapter_7_section_1.html#//apple_ref/doc/uid/TP4000297
    4-CH8-SW45
    >

    -Shawn
  • The hang up that I see is that this documentation give no clue as to
    the reason for File's Owner's existence.

    What problem does it solve?

    Fundamentals mean nothing unless they read like a story: you have to
    give each thing a reason to exist so that the reader has a place to
    mentally hang them.

    On May 23, 2008, at 12:13 PM, Matt Long wrote:

    > I'm trying to figure out why the big hang up on needing to
    > understand it fully. Not understanding it should not prevent you
    > from developing applications. So why the hangup? What is the actual
    > problem? Just set your own NSObject based app delegate as the File's
    > Owner delegate in IB and start adding your code to it. That's really
    > all you *need* to know.
    >
    > -Matt
    >
    >
    >
    > --------------------------
    > Matt Long
    > <matt.long...>
    > http://www.matthew-long.com/
    >
    >
    > On May 23, 2008, at 12:49 PM, Johnny Lundy <johnnylundy...>
    > wrote:
    >
    >> I decided to once again go verbatim through Cocoa Fundamentals. So
    >> far it has been largely "uh-huh, yep", but the File's Owner, my
    >> nemesis, comes up again.
    >>
    >> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CommunicatingWithObjects/chapter_6_section_3.html

    >>
    >>> You connect an outlet in Interface Builder, but the procedure
    >>> starts in Xcode. The following steps describe the procedure:
    >>>
    >>> When defining your custom class, declare an outlet by tagging the
    >>> instance variable with the IBAction qualifier.
    >>> In Interface Builder, drag a generic object into the top level of
    >>> the nib file window (if one doesn’t already exist for your custom
    >>> class).
    >>> If an instance of your custom class is to be the File’s Owner for
    >>> the nib file, this step is not necessary. Also, if you’re defining
    >>> a custom NSView object, select that object instead.
    >>>
    >>> Import the custom class into Interface Builder.
    >>> With the generic object (or File’s Owner) selected, type the name
    >>> of your custom class in the Class field of the Identify pane of
    >>> the Interface Builder inspector. This assigns your custom class as
    >>> the class of the selected object. This step has to be done only
    >>> once.
    >>>
    >>> Select your custom instance (or File’s Owner).
    >>> Right-click or Control-click this object to display the
    >>> connections panel.
    >>> Find your outlet under Outlets and drag a connection line from the
    >>> circle next to the outlet to the object on the user interface that
    >>> you want that outlet to reference.
    >>
    >> I sent feedback on this as File's Owner is mentioned several times
    >> and not defined. There seems to be some huge problem with File's
    >> Owner. Even Aaron Hillegass says that people have trouble
    >> understanding File's Owner - and sure enough, when I read his
    >> explanation, I remained clueless.
    >>
    >> I can follow making a generic NSObject set to my custom class, but
    >> why File's Owner?
    >>
    >> My birthday is coming up and if I can understand File's Owner, I
    >> will consider that one of the best presents.
    >>
    >> As usual, I can recite the documentation without understanding it :
    >> File's Owner is a proxy object that is set at nib load time to the
    >> object that loaded the nib (I don't know what object loaded my nib,
    >> so that does not help me). In MainMenu.nib, this is the application
    >> instance, which is a shared singleton instance of NSApplication
    >> (how all applications can share this is beyond me), which is also
    >> set to the global variable NSApp (uhh, OK...).
    >>
    >> That's all well and good, but what exactly is this thing? Why would
    >> I succeed in having an outlet in my class if I set the Class
    >> Identity of File's Owner to my custom class? Why should I set
    >> File's Owner's Class Identity rather than the Class Identity of a
    >> plain NSObject that I drag out of the Library

  • On Fri, May 23, 2008 at 11:17 PM, Steve Weller <bagelturf...> wrote:

    > The hang up that I see is that this documentation give no clue as to the
    > reason for File's Owner's existence.

    (the first hit on Google for "cocoa file's owner"):

    "You use the File's Owner object as the conduit for connections
    between objects in the nib file and objects outside of it."

    Hamish
  • On Sat, May 24, 2008 at 12:30 AM, Hamish Allan <hamish...> wrote:

    > On Fri, May 23, 2008 at 11:17 PM, Steve Weller <bagelturf...> wrote:
    >
    >> The hang up that I see is that this documentation give no clue as to the
    >> reason for File's Owner's existence.
    >
    >> From
    > http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CoreAppArchitecture/chapter_7_section_8.html

    > (the first hit on Google for "cocoa file's owner"):
    >
    > "You use the File's Owner object as the conduit for connections
    > between objects in the nib file and objects outside of it."
    >

    which then point to "*Further Reading:* You can find out more about nib
    files (including how to dynamically load them) by reading *Resource
    Programming Guide<http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/
    index.html#//apple_ref/doc/uid/10000051i
    >"
    *which explains the anatomy of a nib file:

    "About the File's Owner

    One of the more important concepts to understand when building your nib
    files is what the File's Owner object represents. In Interface Builder, the
    File's Owner object that appears in the nib document window is a proxy for
    an object that your application will provide at runtime. When you
    subsequently load a nib file into your application, your code can specify an
    actual object to take the place of the File's Owner proxy. When you do, any
    nib file connections to File's Owner are automatically made to the object
    you provide (assuming it has the correct outlets and actions).

    The File's Owner object is one of the primary connections your application
    has to the contents of a nib file. File's Owner can be any object in your
    application but is most often set to the controller object that manages the
    corresponding user interface objects in the nib file. By using File's Owner
    in this way, you can isolate the details of your user interface to your
    controller object and let it manage the interactions with other parts of
    your application."

    Indeed, there is no clue ;-)

    --

    Julien
  • Thank you. That is the crucial issue.

    If Aaron says people don't understand it, and I haven't understood it
    even after reading all three editions of his book plus the other two
    Cocoa books plus the Apple documentation many times, then it must be
    difficult.

    On May 23, 2008, at 6:17 PM, Steve Weller wrote:

    > The hang up that I see is that this documentation give no clue as to
    > the reason for File's Owner's existence.
    >

    Exactly. Saying it connects the nib to an object outside the nib
    sounds good, but what object is that? Yes, it is the application
    instance, the NSApp, which handles run loops and delegate methods
    including app launching and app termination. See? I get that. What I
    don't get is "connects the owner to all the other objects in the nib."
    I don't connect any nib objects to File's Owner, and in fact if you
    look at the connections for File's Owner, the only thing it is
    connected to is the About... menu item. It isn't connected to any of
    my NSController instances, or NSObject instances in the nib.

    I have used it to set my class as its delegate so that I could
    implement the delegate method applicationWillTerminate:, and that was
    great. Easy to understand, it calls respondsToSelector: and then calls
    my delegate method. Cool. But as far as the "serves as a proxy for the
    object that owns the nib", why does a nib need an owner? Why do I care
    who the owner is? My NSArrayControllers can be bound to model objects
    without anything going through File's Owner.

    Now if what they are trying to say is that I can bind a controller to
    File's Owner and it will "see" all the properties of all the objects
    in the class that File's Owner is set to, that would be cool. In that
    case it is just serving as an instance of a class and can be used to
    reach properties of objects of that class.

    > What problem does it solve?

    I think I will have to do my usual reverse-engineering: set its Class
    Identity to blank and see what happens to the application.

    I'm not talking about the NSDocument instance as owner, or my own
    owner set when loading my own nib file. Just the routine, MainMenu.nib.

    >
    >
    > Fundamentals mean nothing unless they read like a story: you have to
    > give each thing a reason to exist so that the reader has a place to
    > mentally hang them.

    Well, true, it isn't defined until after they have referred to it
    three times, but even then it's the same thing repeated that I already
    have memorized and don't understand.

    >
    >
    > On May 23, 2008, at 12:13 PM, Matt Long wrote:
    >
    >> I'm trying to figure out why the big hang up on needing to
    >> understand it fully. Not understanding it should not prevent you
    >> from developing applications. So why the hangup? What is the actual
    >> problem? Just set your own NSObject based app delegate as the
    >> File's Owner delegate in IB and start adding your code to it.
    >> That's really all you *need* to know.
    >>
    >> -Matt
    >>
    >>
    >
    Because it must be very important (in fact, people always tell me I
    MUST understand it because it is so fundamental to the Cocoa Core
    Application Architecture), and also the fact that six books can't make
    me understand it.

    My app works without me understanding it; I never touch it except for
    delegation as above. That is not the point.
  • On May 23, 2008, at 5:30 PM, <cocoa-dev-request...> wrote:

    > Message: 3
    > Date: Fri, 23 May 2008 16:55:13 -0400
    > From: Andy Lee <aglee...>
    > Subject: Re: File's Owner
    > To: Cocoa-dev <cocoa-dev...>
    > Message-ID: <EE5C6951-EB08-47A4-B732-6D5D16A10009...>
    > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
    >
    > On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
    >> I decided to once again go verbatim through Cocoa Fundamentals. So
    >> far it has been largely "uh-huh, yep", but the File's Owner, my
    >> nemesis, comes up again.
    >
    > I tried to answer your File's Owner and NSApp questions last week
    > (copied below).  If you can indicate at what point in my explanations
    > you start getting lost, I can try to explain better.
    >
    > Again, I'm sensing a very fundamental disconnect, perhaps more
    > fundamental than you realize.  Anybody can recite documentation, so
    > there's no need to tell us that and no need to recite the
    > documentation. I think it would be more helpful to tell us at what
    > *part* of the documentation you start to get lost, and what
    > specifically is confusing about it, perhaps as relates to your other
    > programming experience.

    The point at which after it says "the proxy is filled in at runtime
    with the object that was set as the owner, ****so that the nib objects
    can communicate with other objects outside the nib*****.

    What other objects outside the nib? I have nothing connected to File's
    Owner except the delegate, and looking at File's Owner's "off the
    shelf" connections, the only one it has is to the About.... menu item.
    So I don't see why any "object outside the nib" could use File's Owner
    to find out about "objects inside the nib", since File's Owner isn't
    connected to any objects inside the nib (except the About... menu item).

    So I understand it's a proxy, I understand it has an object it knows
    as its owner, I know the standard owner is an instance of
    NSApplication aka NSApp global variable, but what I do not get is why
    I need this thing, or how it is needed to "connect the rest of the nib
    objects with an object outside the nib." What object outside the nib?

    > If the answer is that you draw a complete
    > blank, then we shouldn't be addressing that issue at all; you need to
    > step back to a more fundamental level and see if you feel fluent at
    > that level.

    I draw a blank at understanding what it does. I come from a systems
    programming,  BS and MS in CS, from Brown, and all-procedural
    background - assembler in 360, assembler in Meta-4 minicomputers doing
    3-D graphics, taught by Andries van Dam if that means anything, the
    usual litany of procedural languages - Fortran, Basic, PL/I, PL/C, our
    own compiler design close to PL/I but faster, C, (no C++ or Java),
    complete graphics system in assembler like QuickDraw was, visited PARC
    and saw SmallTalk, Snobol, Cobol, MPW/MacApp, 4D databases, 6502
    assembler for processing real-time NMI interrupts for data acquisition
    on the Apple II, Pascal on the early Macs, then since the introduction
    of OS X, several Carbon apps programming the device manager, several
    Cocoa apps, one ported to that platform Apple has that we can't talk
    about, numerous AppleScript Studio apps, which used AppKit
    extensively, tableViews and data sources for them, buttons, target/
    action and outlets, and attended WWDC four times as well as
    maintaining a Select ADC membership for at least 6 years now and
    reviewing all the WWDC videos on Tiger and Leopard recently.

    Whew. That was all for either school or hobby - only worked one summer
    as a real-time systems programmer for Foxboro Corp in Massachusetts
    before leaving for med school.

    But I don't understand File's Owner. Everything else that I listed up
    there, I understood.

    >
    >
    > --Andy
    >
    >
    > Here's my reply from last week:
    >
    > On May 15, 2008, at 11:11 AM, Andy Lee wrote:
    >
    >> On May 14, 2008, at 10:33 PM, Johnny Lundy wrote:
    >>> So it's the application instance. I don't understand what the
    >>> application instance is. I can recite the documentation, which says
    >>> it is a shared instance of NSApplication, also known as NSApp which
    >>> is a global variable, none of which help me.
    >>
    >> To me this indicates a very fundamental disconnect, because what you
    >> recited explains NSApp perfectly.  I can't tell where the disconnect
    >> is, so I'll try to spell this out quickly.  No offense intended here
    >> -- I honestly don't know where the disconnect is.
    >>
    >> You are writing a Cocoa application.  There is a class called
    >> NSApplication that represents the concept of a Cocoa application.
    >> That's the purpose of a class in an object-oriented language, to
    >> describe a *class* of things conceptually.  Classes are usually
    >> named for the thing they describe -- hence "NSApplication".
    >> NSApplication handles the generic things that Cocoa applications do:
    >> managing the main menu, managing the window list, dealing with mouse
    >> and keyboard events, and so on.
    >>
    >> Cocoa applications create objects (instances of classes).  That's
    >> what they do all day.  Objects get created, they send messages to
    >> each other, they get dealloc'ed.  Thousands and thousands of
    >> objects, all day long.  In your application there is one special
    >> object that is an instance of NSApplication.  It represents the
    >> application itself.  I repeat: there is an object in your
    >> application that represents the running application itself.  There
    >> is only one such object, and it is stored in a global variable
    >> called NSApp.  That is what "application instance" means.
    >>
    >>> Why would someone bind to File's Owner? What specifically is it?
    >>
    >> Unlike most other objects in a nib file (First Responder being the
    >> exception), File's Owner is not a specific object.  It is a
    >> placeholder for an "owner" object that will be specified when the
    >> nib file is loaded.  You edit a nib file knowing that it will be
    >> loaded at some point in your program, and *at that future time* the
    >> owner of the file (hence "File's Owner") will be specified.
    >>
    >> The file's owner gives your program access to the objects in the nib
    >> file, through the connections you made to it in the nib.
    >>

    Here's my problem. I didn't make any connections to File's Owner. I
    never have. Before bindings, I had a view object send an action to my
    class, by coding (IBAction) myMethod: in my code, and setting that
    action in the view object's action method.

    With bindings, I bind the view object to the NSArrayController, and
    the controller to an NSObject whose class is set to my custom class.
    Nothing done with File's Owner at all.

    >> I think newcomers sometimes assume that when you load a nib you get
    >> some sort of NibObject that you can query to get at the objects in
    >> the nib, perhaps using the name you assigned in the nib file.  This
    >> is an understandable assumption, but you don't get any such object.
    >> You need to specify a file's owner for the nib (using the second
    >> argument to +loadNibNamed:owner:), and you need to have constructed
    >> the nib so it connects the file's owner to at least one of its
    >> objects.
    >>
    >> --Andy
    >

    I understand that if I wanted to make another nib (which I definitely
    will need at some point), that I invoke loadNIbNamed:owner:, but I
    still wouldn't know why I was specifying an owner. I assume said owner
    would be an object, which might be one of my class instances, but
    really I have no idea.
  • John -

    I'd like to be able to describe the concept of File's Owner and First
    Responder to people clearly. I don't think I would have described it
    any differently than Key Thomases did early today. I've copied his
    explanation below.

    Did you find Ken's explanation helpful?

    Jon Hess

    On May 23, 2008, at 12:33 PM, Ken Thomases wrote:

    > On May 23, 2008, at 1:49 PM, Johnny Lundy wrote:
    >
    >> As usual, I can recite the documentation without understanding it :
    >> File's Owner is a proxy object that is set at nib load time to the
    >> object that loaded the nib (I don't know what object loaded my nib,
    >> so that does not help me).
    >
    > You should know that.  Either it's the MainMenu.nib, which is
    > automatically loaded by the application object (an instance of
    > NSApplication, by default) or you've made explicit other
    > arrangements.  If you've got a nib other than MainMenu.nib, how are
    > you arranging for it to be loaded?  Whatever the answer to that
    > question, it tells you what object will be the File's Owner.
    >
    >> In MainMenu.nib, this is the application instance, which is a
    >> shared singleton instance of NSApplication (how all applications
    >> can share this is beyond me),
    >
    > It's not a singleton across all processes.  That's not the meaning
    > of singleton.  A singleton is usually singular only in the context
    > of a single process.  Basically, the process which is your running
    > application contains one single instance of NSApplication or an
    > NSApplication-derived class.  This object is the File's Owner of
    > MainMenu.nib.
    >
    >> which is also set to the global variable NSApp (uhh, OK...).
    >
    > A pointer to that object, the single instance of NSApplication or a
    > subclass, is stored in a global variable, NSApp.  (Again, just to
    > avoid confusion, "global" within your process, not across all
    > processes.)
    >
    >
    >> That's all well and good, but what exactly is this thing? Why would
    >> I succeed in having an outlet in my class if I set the Class
    >> Identity of File's Owner to my custom class?
    >
    > A nib is a collection of interrelated objects freeze-dried into a
    > file.  When you load a nib, you reconstitute the objects within it
    > and reestablish the connections between them.  However, this object
    > graph would be disconnected from the other objects that already
    > exist within your application, and so would have very restricted
    > ability to interact with them.  You want a way to connect up the two
    > object graphs.
    >
    > So, in your design of your application, you pick some object that
    > exists prior to the nib being loaded as the connection point -- the
    > place where the new objects-to-be-loaded will connect up with your
    > existing objects.  Which of your objects you pick is up to you,
    > although it is often convenient to use an instance of a custom
    > subclass of NSWindowController or NSViewController.
    >
    > The nib has a placeholder in the freeze-dried object graph.  This is
    > like a blank spot on a diagram, where arrows point to it, but
    > there's nothing there, yet.  There can also be arrows pointing out
    > from this blank spot to the other things in the diagram.  When your
    > code decides it's time to load the nib, you specify in that code
    > that the object you picked in the previous paragraph will be the
    > nib's owner.  The nib loading machinery plops the owner object into
    > the blank spot in the diagram.  It already has existing connections
    > to your object graph and now, as part of nib loading, the arrows to
    > and from that blank spot are connected to and from that owner
    > object.  Objects in your nib which had references to the file's
    > owner get references to that object.  Where there were arrows
    > pointing out from the blank spot, those are outlets from your file's
    > owner.  The nib loading machinery sets the outlets on your owner
    > object to point to the newly-created objects from the nib.
    >
    > Now your object graph is integrated, where the new objects have the
    > references to pre-existing objects which they need to access, and at
    > least one of the pre-existing objects has a way of addressing the
    > new objects.
    >
    > The nib needs to be told the class of your (future) file's owner so
    > that it can know what outlets it supports.  It figures this out by
    > parsing the .h file which declares that class, looking for the
    > IBOutlet keyword.  You want to set up outlets so that the owner
    > object has references to the objects that were created by loading
    > the nib.
    >
    >
    >> Why should I set File's Owner's Class Identity rather than the
    >> Class Identity of a plain NSObject that I drag out of the Library
    >> in IB?
    >
    > Because that NSObject would not have any relationship to your pre-
    > existing object graph.  There are sometimes good reasons to drag an
    > NSObject out of the library to instantiate it in the nib, and set
    > its class to one of your own, and then hook it up to the other
    > objects in your nib.  It's just that this serves a different purpose
    > than File's Owner.
    >
    >
    > I hope that helps.
    >
    > Cheers,
    > Ken
  • > On May 23, 2008, at 5:30 PM, <email...> wrote:
    > On May 23, 2008, at 2:49 PM, Johnny Lundy wrote:
    > I decided to once again go verbatim through Cocoa Fundamentals. So
    > far it has been largely "uh-huh, yep", but the File's Owner, my
    > nemesis, comes up again.
    > [deleted]
    > Again, I'm sensing a very fundamental disconnect, perhaps more
    > fundamental than you realize.  Anybody can recite documentation, so
    > there's no need to tell us that and no need to recite the
    > documentation. I think it would be more helpful to tell us at what
    > *part* of the documentation you start to get lost, and what
    > specifically is confusing about it, perhaps as relates to your other
    > programming experience.
    >
    > The point at which after it says "the proxy is filled in at runtime
    > with the object that was set as the owner, ****so that the nib
    > objects can communicate with other objects outside the nib*****.
    >
    > What other objects outside the nib? I have nothing connected to
    > File's Owner except the delegate, and looking at

    STOP.  You just answered your own question.  You connected the
    delegate outlet of an object outside the nib to some object within the
    nib.  That is why File's owner exists!  You just used File's Owner to
    make a connection to an object outside the nib.  That object is the
    application's one and only NSApplication instance.

    > File's Owner's "off the shelf" connections, the only one it has is
    > to the About.... menu item.
    ...AND the delegate IBOutlet that you just said you connected.  Don't
    forget that one.

    > So I don't see why any "object outside the nib" could use File's
    > Owner to find out about "objects inside the nib", since File's Owner
    > isn't connected to any objects inside the nib (except the About...
    > menu item).

    The one and only NSApplication instance outside your nib found out
    about some object in your nib when you made a connection to File's
    Owner telling the NSApplication instance to set its delegate outlet to
    some object inside your nib.
    >
    >
    > So I understand it's a proxy, I understand it has an object it knows
    > as its owner, I know the standard owner is an instance of
    > NSApplication aka NSApp global variable, but what I do not get is
    > why I need this thing, or how it is needed to "connect the rest of
    > the nib objects with an object outside the nib." What object outside
    > the nib?

    Maybe so that you can set the delegate of the NSApplication instance ?

    > [lots of experience that indicates and ability to learn complex
    > information deleted]

    >
    > But I don't understand File's Owner. Everything else that I listed
    > up there, I understood.
    >
    > [deleted]
    > Here's my problem. I didn't make any connections to File's Owner. I
    > never have. Before bindings, I had a view object send an action to
    > my class, by coding (IBAction) myMethod: in my code, and setting
    > that action in the view object's action method.

    You mean except connecting the delegate outlet of the File's Owner.
    >
    >
    > With bindings, I bind the view object to the NSArrayController, and
    > the controller to an NSObject whose class is set to my custom class.
    > Nothing done with File's Owner at all.
    >
    In my opinion, you are not ready to use NSArrayController or bindings.

    > [deleted]
    >
    > I understand that if I wanted to make another nib (which I
    > definitely will need at some point), that I invoke
    > loadNIbNamed:owner:, but I still wouldn't know why I was specifying
    > an owner. I assume said owner would be an object, which might be one
    > of my class instances, but really I have no idea.

    Well, let's see.  If the NSApplication instance outside your
    MainMenu.nib had not been specified as the File's Owner for your nib,
    how would you have made a connection to the NSApplication instance's
    delegate outlet ?

    Please read http://lists.apple.com/archives/Cocoa-dev/2008//May/msg02323.html
      again.

    I despair that I am unable to adequately explain the concept and
    utility of File's Owner to you.  This disturbs me greatly because I
    have written a book about Cocoa Programming, and I explained File's
    Owner in that book.  I fear that I have failed.  If I can't explain
    this concept to a very learned programmer, how can I explain it to a
    true novice.
  • Hi,

    I think you might be making this harder than it needs to be because you
    are expecting the File's Owner of application's main nib file (usually
    MainMenu.nib) to require a lot of wiring up. Generally, it doesn't.

    File's Owner is used to link object from one nib to another. Since your
    main nib is loaded at application start, and is generally not receiving
    messages from objects in other nibs, its File's Owner does not normally
    need to do much.

    File's Owner becomes important when you have more than 1 nib. You will
    generally give it connections to the objects in its own nib that need to
    be controlled from outside. It should also have the signatures of any
    delegate methods, etc. that are needed for the nib objects to receive
    their messages from the outside objects.

    Now, when you need the objects in your second nib, you will load the nib
    and pass in as the owner: an already instantiated object. This object
    will need to have all of the same types of outlets as the second nib's
    File's Owner, and it should implement whatever methods the File's Owner
    has listed.

    However, this object will not actually be wired up to the File's Owner
    object in IB. It will become the File's Owner and be wired up
    programatically when the nib is loaded with this instance object as the
    owner. It will take over the role of File's Owner and be assigned all of
    the connections of the File's Owner for the loaded nib.

    You should view the File's Owner object in IB as a place holder or a
    template. If you consider it a template, then it describes what the
    class that will take its place at run should do.

    I hope the above explanation is helpful. It is my understanding of the
    how/why of File's Owner. It may be slightly off conceptually, but
    practically this understanding has served me well.

    Cheers,
    Jason
  • OK that's the first step towards saying what it is - the controller
    object that manages the corresponding user interface objects in the
    nib file. Now to find out what "managing" them means. This implies
    that NSApp is a "controller object" that manages the user interface
    objects in my nib file. I need to find out what NSApp is doing to my
    nib file objects to "manage" them.

    I'm getting closer. Thanks for the reference.

    On May 23, 2008, at 7:36 PM, Julien Jalon wrote:

    > File's Owner can be any object in your application but is most often
    > set to the controller object that manages the corresponding user
    > interface objects in the nib file.
  • > ...then it must be
    > difficult.

    Actually, no. It is so much simpler and more elegant a solution than other
    frameworks that people have difficulty comprehending precisely because they
    keep trying to make it more complex than it is.

    > Now if what they are trying to say is that I can bind a controller to
    > File's Owner and it will "see" all the properties of all the objects
    > in the class that File's Owner is set to, that would be cool. In that
    > case it is just serving as an instance of a class and can be used to
    > reach properties of objects of that class.

    Yes, exactly: "it will see all the properties of all the objects in the
    class that File's Owner is set to" is what "proxy" means.

    > What other objects outside the nib?

    That's up to you. Although the most general answer would be "your
    application", but that's a bit too vague. The point is, a nib file by itself
    isn't worth much, at some point, somehow, the application has to be able to
    connect to it to gather data, for whatever purpose the application is
    intended. I'm going to take a guess here, that if the sense of the
    documentation were inverted, so that it said "so that objects outside the
    nib can communicate with the nib objects", it might have made more sense to
    you.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • On May 23, 2008, at 9:55 PM, Erik Buck wrote:
    >> What other objects outside the nib? I have nothing connected to
    >> File's Owner except the delegate, and looking at
    >
    > STOP.  You just answered your own question.  You connected the
    > delegate outlet of an object outside the nib to some object within
    > the nib.  That is why File's owner exists!  You just used File's
    > Owner to make a connection to an object outside the nib.  That
    > object is the application's one and only NSApplication instance.

    Exactly -- you answered your own question.

    The application instance is created behind the scenes for you just
    after your application starts launching but before the main nib is
    loaded.  By definition (since the nib hasn't been loaded yet) the
    application instance is outside the nib.  Again: the application
    instance exists *before* MainMenu.nib is ever loaded.  Then, when
    MainMenu.nib *is* loaded, the application instance is set to be the
    File's Owner for that nib.

    >> I had a view object send an action to my class, by coding
    >> (IBAction) myMethod: in my code, and setting that action in the
    >> view object's action method.

    As it turns out, you can do what you just described perfectly well
    without using File's Owner and your application will be just fine.
    The reason is that when your nib file was loaded, your window was
    instantiated (remember that your window is one of the objects
    described in the nib file), and when a window is instantiated it's
    automatically added to the application instance's window list.  So
    this is actually another connection between an object outside the nib
    (the application instance) and objects in the nib (your window or
    windows) -- a connection that is made for you that doesn't require use
    of File's Owner.  None of us thought to mention this connection (that
    I recall), because we were focused on the general explanation of
    File's Owner.

    Again, if any of this or anyone else's answer is not clear, please try
    to help us help you by pinpointing *where* we start to lose you.

    --Andy
  • OK, maybe an example will help. Jason's point about File's Owner having more
    outlets and "more to do" in nibs other than MainMenu.nib is good.

    Assume you're writing some kind of database app. Assume you're creating a
    nib for the "contact entry" screen. Assume a nib for this screen with
    various controls on it, and a class for this screen that starts off like
    this:

    @interface ContactWindowController : NSWindowController
    {
        IBOutlet id firstNameTxt;
        IBOutlet id lastNameTxt;
        IBOutlet id addressTxt;
        IBOutlet id phoneTxt;
        IBOutlet id commentsTxt;

        IBOutlet id saveBtn;
    }
    ...
    @end

    So what do you want to do here? Well, you want to open a window based on the
    nib, with all those controls displayed. And you want an instance of your
    class. And you want your class members hooked up to those controls that are
    displayed. Right? So how to do this?

    Well, first, create the nib, then set the class of File's Owner to
    ContactWindowController, then wire up those outlets of File's Owner to
    firsNameTxt and so on. Also, set the File's Owner "window" outlet (inherited
    from NSWindowController) to the window, and set the window's delegate to
    NSWindowController (not used in this example, but required for any real
    use).

    Next, add this method to ContactWindowController:

    - (id) init
    {
        [super initWithWindowNibName: "newcontact.nib" owner: self];
    }

    Now, call the following somewhere in your application (probably in a method
    of your app delegate, probably wired up to a menu item in MainMenu.nib):

    ContactWindowController  *wc = [[ContactWindowController alloc] init];

    There you have it: wc is now an instance of ContactWindowController, and its
    firstNameTxt et al instance variables all point to the controls in the
    window which is set up with those controls. Sort of.

    There's one subtlety in that much of the set up of the window is "lazy" and
    doesn't actually happen until you ask for the window via the "window"
    method. In other words, much of the magic doesn't happen until you call:

    [wc window]

    But this hardly matters because, except in unusual circumstances, the very
    next thing you're going to do with your controller after creating it is:

    [[wc window] makeKeyAndOrderFront: wc]

    In order to actually display the window and bring it to the front.

    And of course if you add the following method to your class

    - (id) doSaveBtn: (id) sender
    {
        // save all the data to the database
        // left as an exercise to the reader since it's totally trivial ;-)
    }

    And wire up the button to File's Owner doSaveBtn:, then when the use clicks
    the save button, the method will be called, and the data will be saved. Or
    not, depending on various minor details, like the state of the connection to
    the database ;-)

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • An example of multiple nibs where a nib's File's Owner wouldn't
    necessarily be NSApp would be System Preferences and the
    preferencepane bundles that it loads.

    NSApp would be SystemPreferences.app, and owns the main nib of the
    application.

    Each preference pane is an instance of NSPreferencePane (or a
    subclass), which is the owner of a nib that provides the user
    interface that loads in when you select the pane.

    So in that case, NSApp owns a nib, but also has a collection of
    NSPreferencePane objects, each of which owns a nib.

    Conceivably, an NSPreferencePane object might be paired with one or
    more other classes (for example, a class to load and display screen
    saver previews) which might want access to the pane's user interface
    widgets or their data. It would access those indirectly through the
    preference pane, which is connected to the widgets using the File's
    Owner proxy.

    On May 23, 2008, at 10:31 PM, Johnny Lundy wrote:

    > OK that's the first step towards saying what it is - the controller
    > object that manages the corresponding user interface objects in the
    > nib file. Now to find out what "managing" them means. This implies
    > that NSApp is a "controller object" that manages the user interface
    > objects in my nib file. I need to find out what NSApp is doing to my
    > nib file objects to "manage" them.
    >
    > I'm getting closer. Thanks for the reference.
    >
    >
    >
    >
    > On May 23, 2008, at 7:36 PM, Julien Jalon wrote:
    >
    >> File's Owner can be any object in your application but is most
    >> often set to the controller object that manages the corresponding
    >> user interface objects in the nib file.

  • Am 24.05.2008 um 03:55 Uhr schrieb Erik Buck:

    > That is why File's owner exists!  You just used File's Owner to make
    > a connection to an object outside the nib.

    I thought, maybe a picture would help:

    http://www.harmless.de/images/other/files_owner.png

    On the left would be the scenario without a File's Owner proxy.
    Note that, after loading the nib, there is no way to reach the newly
    added objects from the old ones.

    On the right you can see what purpose the File's Owner serves.
    The outline indicates, that it is not a real object, but just a kind
    of placeholder for one.
    Now when an object - in this case NSApp - get's substituted for the
    file's owner, it takes the pace of the former proxy object. The
    outcome is, that you now *do* have a connection from the original
    object graph to the newly added one.

    Andreas
  • On 24 May 2008, at 05:39, Andreas Mayer wrote:
    >
    > I thought, maybe a picture would help:
    >
    > http://www.harmless.de/images/other/files_owner.png

    Exactly the picture I was about to draw.

    Johnny Lundy wrote:
    > Saying it connects the nib to an object outside the nib sounds good,
    > but what object is that?

    The object that loaded the NIB. What object is that? Whichever is
    passed when the NIB is loaded with [NSBundle loadNibNamed:owner:]

    e.g. NSApplication probably has code that looks like

    [NSBundle loadNibNamed:@"MainMenu" owner:self]

    You might have a piece of code that reads

    [NSBundle loadNibNamed:@"InspectorWindows" owner:inspectorController]
  • On Sat, May 24, 2008 at 6:49 AM, Paul Sargent <psarge...> wrote:

    >
    > On 24 May 2008, at 05:39, Andreas Mayer wrote:
    >
    >>
    >> I thought, maybe a picture would help:
    >>
    >> http://www.harmless.de/images/other/files_owner.png
    >>
    >
    > Exactly the picture I was about to draw.
    >
    > Johnny Lundy wrote:
    >
    >> Saying it connects the nib to an object outside the nib sounds good, but
    >> what object is that?
    >>
    >
    > The object that loaded the NIB. What object is that? Whichever is passed
    > when the NIB is loaded with [NSBundle loadNibNamed:owner:]
    >
    > e.g. NSApplication probably has code that looks like
    >
    > [NSBundle loadNibNamed:@"MainMenu" owner:self]
    >
    > You might have a piece of code that reads
    >
    > [NSBundle loadNibNamed:@"InspectorWindows" owner:inspectorController]

    If your inspectorController is your own custom subclass of
    NSWindowController, it will make itself the nib's owner if you create it
    like this:

    MyInspectorController* ic = [[MyInspectorController alloc] initWithNibName:@
    "inspectorWindows"];

    sherm--

    --
    Cocoa programming in Perl: http://camelbones.sourceforge.net
  • On Sat, May 24, 2008 at 1:21 AM, Johnny Lundy <johnnylundy...> wrote:

    > I have used it to set my class as its delegate so that I could implement the
    > delegate method applicationWillTerminate:, and that was great. Easy to
    > understand, it calls respondsToSelector: and then calls my delegate method.
    > Cool. But as far as the "serves as a proxy for the object that owns the
    > nib", why does a nib need an owner? Why do I care who the owner is? My
    > NSArrayControllers can be bound to model objects without anything going
    > through File's Owner.

    They can indeed. You can use your nib-instantiated controller object's
    awakeFromNib method to set up your model objects, and wire your main
    menu's Open and Save items directly to methods in that controller. But
    if you ever want to use more than one controller, you'll probably have
    to start using methods like applicationDidFinishLaunching: (for
    synchronisation). That code path, as well as
    applicationWillTerminate:, goes through an object outside your nib
    (NSApplication), even though it's subsequently calling a delegate
    method inside your nib.

    Incidentally, have you ever written a document-based cocoa app?

    > Now if what they are trying to say is that I can bind a controller to File's
    > Owner and it will "see" all the properties of all the objects in the class
    > that File's Owner is set to, that would be cool.

    That is exactly what they are saying.

    > In that case it is just
    > serving as an instance of a class and can be used to reach properties of
    > objects of that class.

    Well, it's serving as a *proxy* for an *existing* instance of a class.
    Whereas instantiating an NSObject in the nib creates an instance and
    allows you to make connections to it, you can use File's Owner to make
    connections to an object that exists prior to loading of, and outside
    of, the nib.

    Hamish
  • I dunno. Your book seems to be one of the few, if not the only, that
    is not on my bookshelf.

    If you email me your page on File's Owner, I can give feedback.

    On May 23, 2008, at 9:59 PM, <cocoa-dev-request...> wrote:

    > I despair that I am unable to adequately explain the concept and
    > utility of File's Owner to you.  This disturbs me greatly because I
    > have written a book about Cocoa Programming, and I explained File's
    > Owner in that book.  I fear that I have failed.  If I can't explain
    > this concept to a very learned programmer, how can I explain it to a
    > true novice.
  • On May 23, 2008, at 7:21 PM, Johnny Lundy wrote:

    > My NSArrayControllers can be bound to model objects without anything
    > going through File's Owner.

    Really?  That implies that your model is contained within the nib,
    which is not how MVC is supposed to work.  The nib should contain the
    V (View) and possibly C (Controller) parts of MVC, but it should not
    contain the M (Model).  One of the points of separating Model from
    View from Controller is that you can have multiple different views on
    the same model.  Imagine an application which represents a set of
    numbers in one window in a table and in another window in a graph.
    These two windows can (and probably should) be described in separate
    nibs, and the model should live in neither.  It should be instantiated
    in code somewhere else in your application, or managed with Core Data,
    etc.  File's Owner would be needed to connect the views and
    controllers in the nibs to the model.

    Perhaps you need to review the "Model-View-Controller Design Pattern"
    conceptual documentation in the Cocoa Fundamentals Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
    /CocoaDesignPatterns/chapter_5_section_4.html
    >.

    No offense, but your queries to this list remind me of the way
    children can ask "Why?" infinitely.  No matter what explanation is
    provided, they can reflexively ask "Why?" about that new explanation.

    So, you've been told by the documentation and by the respondents here
    on this list that File's Owner is useful and important.  And you don't
    yet see how or why.  That's OK.  It just hasn't been important to you
    _yet_.  If it bothers you, you can go about your work (as you appear
    to have) without making much use of File's Owner.  Eventually, you
    will want or need to do something which becomes difficult or
    impossible to do without using File's Owner -- and _then_ you'll know
    how it is useful.

    I get the impression that, although you are greatly vexed and
    frustrated by not yet understanding the purpose and usefulness of
    File's Owner, you are not actually putting in much effort into
    figuring that out for yourself.  (This is what puts me in mind of the
    "Why?" game that children sometimes play.  I may be wrong here, and if
    I am I apologize in advance.)

    For example, have you exercised your imagination to try to come up
    with scenarios where it might be useful?  From your more recent
    emails, you actually seem to have a good grasp of what File's Owner
    does.  And I must assume you have a general understanding of why it is
    useful for some objects to have references to other objects.  So, why
    is it that you can't see why it might, in some circumstances, be
    useful for objects in a nib to have references to objects outside of
    the nib, and vice versa?  "Why?"  For all the myriad reasons that
    objects need references to other objects.  There's no one answer.
    "None of my nibs have had that requirement."  So?  Does that limited
    empirical result prove, or even imply, that no nibs might, ever?

    Have you examined any of the example programs that Apple supplies?  Do
    you realize that the full source for TextEdit comes with the developer
    tools (/Developer/Examples/AppKit/TextEdit)?  Other sample projects
    with multiple nibs include BlastApp, iSpend, and Sketch.  Have you
    examined how those examples use their nibs, and looked to see what
    connections they make to, from and through the owners of those nibs?

    When you read Apple design guidelines regarding nibs, do you dismiss
    them or do you consider adopting them?  Of course, you don't always
    have to adopt them -- they're only guidelines after all.  But have you
    considered how adopting them would affect the way you design your
    nibs?  Obviously, the features (such as File's Owner) of the framework
    and the tools are often useful when you do follow the guidelines.  For
    example, see:

    http://developer.apple.com/documentation/DeveloperTools/Conceptual/IB_UserG
    uide/BuildingaNibFile/chapter_4_section_7.html

    http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/
    CocoaNibs/chapter_3_section_5.html


    I suppose I should step off of my soapbox.  Sorry for the lecture, but
    many people have been trying to help and none of us seem to have
    gotten through.

    Regards,
    Ken
  • Well, tell that to the guy who wrote the Currency Converter Using
    Bindings tutorial. See the last sentence here:

    "This concrete example should help you understand what the value
    binding’s configuration implies: The content of the text field is
    bound to the value of the exchangeRate key, which Cocoa bindings finds
    on the model object using key-value coding. Cocoa bindings knows to
    look for that key in the model object that is bound to thecontent
    outlet of the controller specified by the Bind to aspect—in this
    example, the controller is theNSObjectController instance you
    configured earlier, whose content outlet points to the Converter
    object you instantiated in the nib file."

    And you wonder why I am still confused. That paragraph from Apple
    directly contradicts what you just said.

    The Converter object is continually referred to as the Model Object.
    That is exactly how mine are set up - connected to the Controller
    Object. The tutorial says nothing about File's Owner.

    And, if I don't understand something, I will ask why. This is not
    magic - there is actual computer code behind that File's Owner
    concept, and it is deterministic, not vague, not abstract, not a
    philosophical enigma, not random, not ambiguous. If I had the source
    code I could see what it does.

    Despite teaching OB/GYN for 17 years, this is why computer science is
    always my main interest. I've written firmware before we called it
    firmware. I have never NOT been able to grasp something until this and
    bindings. Aaron says lots of people have trouble understanding File's
    Owner, so I can only conclude that it's the documentation, or lack
    thereof.

    And yes, I have read that MVC thing over and over and over.

    On May 25, 2008, at 2:12 AM, <cocoa-dev-request...> wrote:

    >>
    >> My NSArrayControllers can be bound to model objects without anything
    >> going through File's Owner.
    >
    > Really?  That implies that your model is contained within the nib,
    > which is not how MVC is supposed to work.  The nib should contain the
    > V (View) and possibly C (Controller) parts of MVC, but it should not
    > contain the M (Model).
  • On May 25, 2008, at 3:15 AM, Johnny Lundy wrote:

    > Well, tell that to the guy who wrote the Currency Converter Using
    > Bindings tutorial. See the last sentence here:
    >
    > "This concrete example should help you understand what the value
    > binding’s configuration implies: The content of the text field is
    > bound to the value of the exchangeRate key, which Cocoa bindings
    > finds on the model object using key-value coding. Cocoa bindings
    > knows to look for that key in the model object that is bound to
    > thecontent outlet of the controller specified by the Bind to aspect—
    > in this example, the controller is theNSObjectController instance
    > you configured earlier, whose content outlet points to the Converter
    > object you instantiated in the nib file."
    >
    > And you wonder why I am still confused. That paragraph from Apple
    > directly contradicts what you just said.
    >

    In a real application of any substance you'd likely create your model
    object dynamically (from saved data or a new state which you intend to
    be able to save and load in the future).

    In this _specific_ example (which is what that last sentence says) the
    model object is being instantiated in the nib. This is because the
    creation of the model object isn't what the example is attempting to
    show... it's the connections between the objects and creating them in
    IB.

    (it isn't a particularly extensive bindings example (purposely), it is
    out of date (old Xcode and IB), and needs a total rewrite and
    expansion...)

    >
    >
    > On May 25, 2008, at 2:12 AM, <cocoa-dev-request...> wrote:
    >
    >>>
    >>> My NSArrayControllers can be bound to model objects without anything
    >>> going through File's Owner.
    >>
    >> Really?  That implies that your model is contained within the nib,
    >> which is not how MVC is supposed to work.  The nib should contain the
    >> V (View) and possibly C (Controller) parts of MVC, but it should not
    >> contain the M (Model).

  • On 25 May '08, at 12:15 AM, Johnny Lundy wrote:

    > And you wonder why I am still confused. That paragraph from Apple
    > directly contradicts what you just said.

    In some cases model objects are instantiated directly in nib files,
    but it's not typical. It generally happens if the model object is a
    singleton, so there's no need to overgeneralize the code by creating
    instances dynamically. This most often happens in deliberately-
    simplified tutorial code ... like Currency Converter.

    > And, if I don't understand something, I will ask why. This is not
    > magic - there is actual computer code behind that File's Owner
    > concept, and it is deterministic, not vague, not abstract, not a
    > philosophical enigma, not random, not ambiguous. If I had the source
    > code I could see what it does.

    It's not really complicated. "File's owner" in the nib is just a
    placeholder for the actual object that the nib is being loaded on
    behalf of at runtime. It's just like boilerplate phrases like "the
    party of the first part" in a legal contract.

    The underlying call in NSBundle to load a nib takes an "owner" as a
    parameter; so NSBundle loads the nib into memory, and wherever it
    finds a reference in the nib to "file's owner", it just substitutes
    the actual "owner" object that it was given. The effect is that the
    IBOutlet instance variables in that owner object get filled in with
    pointers to objects in the nib, and other objects in the nib get
    pointers to the owner object.

    So when an NSWindowController loads its nib, it calls [NSBundle
    loadNibNamed: @"MyDocument.nib" owner: self]. The nib loading process
    then uses the NSWindowController object wherever the nib says "file's
    owner". The end result is that the controller's outlets now point to
    view objects instantiated from the nib, and those objects have target
    outlets that point back to the controller.

    If another window controller loads the same nib later on, it becomes
    the "file's owner" for that instantiation, and the new views that get
    loaded from the nib that time get pointed to this other controller,
    and vice versa.

    —Jens
  • On May 25, 2008, at 2:15 AM, Johnny Lundy wrote:

    > And, if I don't understand something, I will ask why. This is not
    > magic - there is actual computer code behind that File's Owner
    > concept, and it is deterministic, not vague, not abstract, not a
    > philosophical enigma, not random, not ambiguous. If I had the source
    > code I could see what it does.

    But your most recent emails explain that you already understand _what_
    it does, and you were only confused about the why!  Looking at the
    source code wouldn't help with the why.

    As I attempted to explain, you will come to understand the why with
    experience.  Since you seem vexed about not understanding it now, I
    suggested that you take a look at some of the sample code which uses
    File's Owner in non-trivial ways.  I also provided a quickie
    conceptual example of an application which presents one model in two
    views.

    Another quickie conceptual example: the classic document-based
    application architecture.  In that architecture, you often re-use a
    single nib, loading it repeatedly.  That nib describes the interface
    for a single document.  But the application can open multiple
    documents.  That is, it has multiple models.  Note that in this case,
    the model can't live in the nib -- it's coming from a document file
    somewhere.  Each time the application loads the nib for a document's
    interface, the new objects from that nib have to connect up to a
    different model/document.  They do this through the File's Owner,
    which is a different object for each loading of the nib.

    -Ken
  • On 25 May 2008, at 08:15, Johnny Lundy wrote:

    > Well, tell that to the guy who wrote the Currency Converter Using
    > Bindings tutorial. See the last sentence here:

    [...]

    > And you wonder why I am still confused. That paragraph from Apple
    > directly contradicts what you just said.
    >
    > The Converter object is continually referred to as the Model Object.
    > That is exactly how mine are set up - connected to the Controller
    > Object. The tutorial says nothing about File's Owner.

    That's a rather unfortunate example for you because it's a tutorial
    directly targeted at learning the basics of bindings. It's more
    convenient for the tutorial to instantiate a model object in the NIB,
    but you wouldn't normally do that in a larger application. It would
    make it a pain to access the model from other NIBs for example.

    Normally your model objects would be created in code that didn't care
    about NIBs or any UI objects. Then you would have a few NIBs that deal
    with different aspects of your application and they have to access the
    shared model objects (shared amongst all NIBs). How would the
    controllers in these NIBs access the model? Via one of the proxy
    objects. Which one (Application or File's Owner) depends on whether
    the model is a global resource or something specific like a document.
    It also depends on the NIB and what it expects its owner to be.

    If you look through the apple samples instead, you can find examples
    of different ways of instantiating NIBs and different ways of binding
    to model objects (that hopefully aren't in the NIBs).

    Examples:

      A simple application with one model and a MainMenu.nib
          As the NIB is loaded by the AppKit automagically, File's Owner
    is just the application object - same as the Application proxy

      A document-based application with a MyDocument.nib
          The NIB is loaded by the AppKit and File's Owner is the window
    controller.
          Access to the document and its model is via the File's Owner.
          Access to global data is via the Application proxy.

      A custom application with NIBs for custom views.
        The NIB is loaded from custom code and File's Owner is whatever
    you set it to - probably a subclass of NSViewController.
        Access to model objects specific to that instance of the view
    would be through the File's Owner.
        Global data via the Application Proxy.

    One last thing: Setting the class of File's Owner in interface builder
    is only so that IB can see what outlets and actions it has. It doesn't
    change what is actually there because the real object is created
    before the NIB is loaded.

    pt.
  • On May 25, 2008, at 3:49 PM, Scott Anguish wrote:

    >
    > On May 25, 2008, at 3:15 AM, Johnny Lundy wrote:
    >
    >> Well, tell that to the guy who wrote the Currency Converter Using
    >> Bindings tutorial. See the last sentence here:
    >>
    >> "This concrete example should help you understand what the value
    >> binding’s configuration implies: The content of the text field is
    >> bound to the value of the exchangeRate key, which Cocoa bindings
    >> finds on the model object using key-value coding. Cocoa bindings
    >> knows to look for that key in the model object that is bound to
    >> thecontent outlet of the controller specified by the Bind to aspect—
    >> in this example, the controller is theNSObjectController instance
    >> you configured earlier, whose content outlet points to the
    >> Converter object you instantiated in the nib file."
    >>
    >> And you wonder why I am still confused. That paragraph from Apple
    >> directly contradicts what you just said.
    >>
    >
    >
    > In a real application of any substance you'd likely create your
    > model object dynamically (from saved data or a new state which you
    > intend to be able to save and load in the future).
    >
    > In this _specific_ example (which is what that last sentence says)
    > the model object is being instantiated in the nib. This is because
    > the creation of the model object isn't what the example is
    > attempting to show... it's the connections between the objects and
    > creating them in IB.
    >
    > (it isn't a particularly extensive bindings example (purposely), it
    > is out of date (old Xcode and IB), and needs a total rewrite and
    > expansion...)
    >>

    I would say that a lot of the 'beginner' code is a bit like this, if
    it does have a View, Controller and Model they are all instantiated in
    the NIB, so I can see where some of the confusion comes from, in fact
    I've now gotten confused again myself.

    Imagine that I have a model with two properties, number and its
    square, something much like the currency converter. Ok I've written my
    model object, it generates events when things change so if you set the
    number, it computes the square and tells anyone listening about it.

    View is easy - I have two text boxes.

    Then I write a controller which has outlets for the two text boxes,
    and connections to the view so it knows when the text boxes update,
    and it is able to set properties on a model, and listen to the events
    on the model. ie lots of glue code.

    So the idea is I type a number in the text box, the controller gets
    notified of the change, gets the number, sets the property on the
    model. The model computes the square and notifies anyone listening
    that it changed, the controller is listening, sees the change, gets
    the new square and sets the text box on the view.

    That's my setup . So now I put the view and the controller in the NIB
    and I don't instantiate a model object in the NIB because I want to do
    that in code. This is a standard non-document application.

    Where do I make the model object and how do I hook it into the
    controller? I start the application, the Files Owner is the singleton
    NSApplication, I guess I can override the NIB finished loading method,
    make the model object there and now I want to call something on the
    controller like ...

    -(Controller)hereIsYourModelObject:(Model*)model

    where the controller caches the model object and registers to listen
    for events. But .. how do I get the controller object in this case to
    make the call?

    Do I subclass NSApplication, adding an outlet for the Controller, make
    the application class my subclass (instead of Application) so that
    Files Owner has that outlet and hook that to Files Owner in IB ? In
    that way when the NIB is instantiated, Files Owner's Controller outlet
    will be set to my Controller, I can then use nsapp.controller
    directly. (actually can I, is NSApp a global static variable which can
    be used from any class as I'll be in an awakeFromNIB() class method
    somewhere)?

    Or was this entire thing the wrong way to do it? Should I have had TWO
    NIBS, one with nothing but the menu in it, and one with my Controller
    and View. The second NIB has, as Files Owner type, the Model and I set
    up the connections to it in IB. Then, when the application starts, I
    have an awakeFromNIB() method in something in the first NIB where I
    create a Model object and then load the second NIB with my Model as
    the Files Owner object?

    I know this is a bit silly, for a singleton like that you may as well
    just put the model in there, but I'm trying to figure out if you
    didn't, what the right way to hook it up to the controller is later.
  • On May 25, 2008, at 2:01 AM, Roland King wrote:

    > Where do I make the model object and how do I hook it into the
    > controller? I start the application, the Files Owner is the
    > singleton NSApplication, I guess I can override the NIB finished
    > loading method, make the model object there and now I want to call
    > something on the controller like ...
    > -(Controller)hereIsYourModelObject:(Model*)model
    >
    If you override -awakeFromNib then you'd do so in the controller
    class, so it would create and set its own model.  There's no need to
    invoke a separate hereIsYourModelObject: method, except in the sense
    of a setModelObject: accessor.
    Alternatively you could do it in -init...

    This is akin to, in the document architecture, the document object
    setting its model by retrieving it from a file.

    > Do I subclass NSApplication
    >
    No, you should almost never subclass NSApplication.  You would use
    delegation instead.

    mmalc
  • On May 25, 2008, at 4:14 AM, mmalc crawford wrote:

    > On May 25, 2008, at 2:01 AM, Roland King wrote:
    >
    >> Where do I make the model object and how do I hook it into the
    >> controller? I start the application, the Files Owner is the
    >> singleton NSApplication, I guess I can override the NIB finished
    >> loading method, make the model object there and now I want to call
    >> something on the controller like ...
    >> -(Controller)hereIsYourModelObject:(Model*)model
    >>
    > If you override -awakeFromNib then you'd do so in the controller
    > class, so it would create and set its own model.  There's no need to
    > invoke a separate hereIsYourModelObject: method, except in the sense
    > of a setModelObject: accessor.
    > Alternatively you could do it in -init...
    >
    > This is akin to, in the document architecture, the document object
    > setting its model by retrieving it from a file.

    Another approach is to not put the controller in the nib.  Have the
    controller be the File's Owner.  So, the controller is created in code
    in response to some action or notification or delegate method (e.g.
    applicationWillFinishLaunching:).  Then the nib is loaded, and the
    controller is passed in as its owner.  In the nib, everywhere that you
    had a connection to or from the controller, you make that connection
    to or from the File's Owner.

    Cheers,
    Ken
  • On May 25, 2008, at 12:15 AM, Johnny Lundy wrote:

    > And, if I don't understand something, I will ask why.
    >
    Here are some suggestions as to how you might pose your questions:
    <http://www.catb.org/~esr/faqs/smart-questions.html>

    > This is not magic - there is actual computer code behind that File's
    > Owner concept, and it is deterministic, not vague, not abstract, not
    > a philosophical enigma, not random, not ambiguous. If I had the
    > source code I could see what it does.
    >
    But that's where you're leading yourself astray -- there isn't any
    source code to see.  The nib file is an object graph with a hole in
    it.  The File's Owner is the hole -- the one thing that *isn't*
    created in the nib.

    This is a *very rough* approximation:

    @interface MyNibManager : NSObject
    {
    }
    - (void)createNibForWindowWithButton:(NSString *)fileName;
    - (void)loadNibForWindowWithButton:(NSString *fileName) withOwner:
    (id)filesOwner;

    @end

    @implementation MyNibManager

    - (void)createNibForWindowWithButton:(NSString *)fileName {

    NSRect contentRect = NSMakeRect(100, 200, 400, 300);
    NSWindow *aWindow = [[NSWindow alloc] initWithContentRect:contentRect
    styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO];

    NSRect buttonFrame = NSMakeRect(10, 20, 80, 20);
    NSButton *aButton = [[NSButton alloc] initWithFrame:buttonFrame];
    [aButton setButtonType:NSMomentaryLightButton];
    [aButton setTitle:@"Push Me"];
    [aButton setAction:@selector(myAction:)];
    [aButton setTarget:(id)-1]; // pretend kludge to represent File's Owner
    // Notice that there's no code for File's Owner itself

    [[aWindow contentView] addSubview:aButton];

    NSArray *tloArray = [NSArray arrayWithObject:aWindow];

    NSDictionary *nib = [NSDictionary dictionaryWithObject:tloArray
        forKey:@"TopLevelObjects"];

    [NSKeyedArchiver archiveRootObject:nib toFile:fileName]
    }

    - (void)loadNibForWindowWithButton:(NSString *fileName) withOwner:
    (id)filesOwner {

    NSDictionary *nib = [NSKeyedUnarchiver
    unarchiveObjectWithFile:fileName];

    NSArray *tloArray = [nib objectForKey:@"TopLevelObjects"];

    [filesOwner setWindow:[tloArray objectAtIndex:0]];

    NSTextField *aButton = [[[window contentView] subViews] objectAtIndex:
    0];
    [filesOwner setButton:aButton];

    if ([button target] == (id)-1) {
      [button setTarget:filesOwner];
    }
    }


    @end

    @interface MyFilesOwner : NSObject
    {
    IBOutlet NSWindow *window;
    IBOutlet NSButton *button;
    }

    @property NSWindow *window;
    @property NSButton *button;

    - (IBAction)myAction:sender;

    @end

    @implementation MyFilesOwner

    @synthesize window, button;

    - (IBAction)myAction:sender {
    NSLog(@"Button pressed");
    }

    - (void)dealloc {
    [window release];
    [button release];
    [super dealloc];
    }

    @end

    int main(int argc, char *argv[])
    {
    NSString *fileName = [NSHomeDirectory()
    stringByAppendingPathComponent:@"MyInterface.mnib"];

    MyNibManager *myNibManager = [[MyNibManager alloc] init];
    [myNibManager createNibForWindowWithButton:fileName];

    MyFilesOwner *filesOwner = [[MyFilesOwner alloc] init];
    [myNibManager loadNibForWindowWithButton:fileName ithOwner:filesOwner];

    // ...
    }

    > Despite teaching OB/GYN for 17 years, this is why computer science
    > is always my main interest.
    >

    Perhaps it's your background that's causing you the problem.  My
    father was Dr. J. Selwyn Crawford.  I persuaded him to buy a Mac in
    1986.  He somehow failed to understand (a rarity) that when you use a
    word processor you don't have to put Returns at the end of the line...

    > I've written firmware before we called it firmware. I have never NOT
    > been able to grasp something until this and bindings. Aaron says
    > lots of people have trouble understanding File's Owner, so I can
    > only conclude that it's the documentation, or lack thereof.

    >
    I think this is a fallacious conclusion.  There are numerous
    descriptions of File's Owner, and people typically read many of them.
    My perspective, after teaching this for some time, is that some people
    simply have difficulty understanding that it's as easy as it is.  It's
    got to be more complicated...
    It isn't.

    Interface Builder is a WYSIWYG object graph editor.
    A nib file is an archived object graph.
    File's Owner is a place-holder for an object created outside of the
    nib that is made the "owner" of the object graph when the object graph
    is unarchived (i.e. when the nib file is loaded).
    When the nib file is loaded, any connections you made between objects
    in the object graph and the File's Owner are reestablished using the
    object set to be the owner (typically in -loadNibNamed:owner:).

    mmalc
  • On 25 May 2008, at 5:15 pm, Johnny Lundy wrote:

    > And, if I don't understand something, I will ask why. This is not
    > magic - there is actual computer code behind that File's Owner
    > concept, and it is deterministic, not vague, not abstract, not a
    > philosophical enigma, not random, not ambiguous. If I had the source
    > code I could see what it does.
    >
    > Despite teaching OB/GYN for 17 years, this is why computer science
    > is always my main interest. I've written firmware before we called
    > it firmware. I have never NOT been able to grasp something until
    > this and bindings. Aaron says lots of people have trouble
    > understanding File's Owner, so I can only conclude that it's the
    > documentation, or lack thereof.

    Here's my simple-minded mental model of File's Owner.

    1. A nib is a file. File's Owner is thus the nib's "owner". An owner
    is any object that agrees to act as a manager for some other objects.

    2. A nib is also, from another point-of-view, a pre-built box of
    objects (pre-built by you, using Interface Builder).

    3. Inside the box, objects can only connect to each other - it's a
    closed system, so they are useless to the outside world, unless you
    have a "connector" or "opening" or "port" (pick your own metaphor)
    into and out of the box. File's Owner is that opening.

    4. When the nib is loaded by some code (either some you've written or
    indirectly by other parts of Cocoa), the owner object is supplied by
    this code. All the connections made in IB to File's Owner are switched
    over to the identically named outlets and action methods defined in
    the real owner object. The icon you see labelled "File's Owner" in IB
    is just a pretend object - the real one is substituted for it when the
    nib is loaded, and that's all. To use a technical term, it's a proxy.
    It's not magic - when the nib is loaded some code simply iterates
    through the list of outlets and actions, finds the same ones in the
    real object and copies the various pointers and selectors that point
    both into the box (outlets) and out of the box (actions) to where they
    need to be to actually function.

    That really is the top and bottom of it. I think you're confusing
    yourself by trying to square this with MVC and Bindings and other
    things. They are not related, except in so far as being a real object
    that you supply, File's Owner has to fit into the rest of the design
    *as well* as performing this duty as the I/O port into the box (nib),
    but that additional responsibility is of no concern to the nib or the
    nib loading code.

    The other thing that may be confusing you is that some example code
    (like the Currency Converter you mention, though I'm not familiar with
    it so I may be wrong) take the convenience of nibs a bit further to
    cut down on the amount of code you need to write to understand the
    point of the tutorial. Many tutorials are like this - they are often
    aimed at demonstrating one specific thing, and take short cuts or
    exhibit poor code practices in other areas unrelated to their main
    point to save time. So, since a nib file is just a box of pre-built
    objects, they can be any sort of object, including those that in a
    better-written app shouldn't really be there, like model objects.
    Whether a nib is (ab)used like this has no bearing on the meaning of
    File's Owner, which is only the opening into the box *and nothing
    more* in the context of the nib itself.

    hth,

    G.
  • On May 25, 2008, at 6:20 AM, mmalc crawford wrote:
    > On May 25, 2008, at 12:15 AM, Johnny Lundy wrote:
    >
    >> And, if I don't understand something, I will ask why.
    >>
    > Here are some suggestions as to how you might pose your questions:
    > <http://www.catb.org/~esr/faqs/smart-questions.html>

    I hesitate to re-enter this thread, I really do.  But I think those of
    us who have been trying to help might want to re-consider how we've
    been answering, as well as how the questions have been posed.  There
    have been many fine, thorough answers to Johnny's question.  The fact
    that none of them have seemed to help should tell us something.

    If I can make a rough analogy, many of our answers have been like
    different re-implementations of an algorithm.  Like the guy on the
    guillotine in that engineer joke, we each think we see what the
    problem is.  And so we "recode" the algorithm our own way, "run" it --
    i.e., post our new, improved explanation -- and find it still fails. [1]

    I submit that instead of recoding the "explain File's Owner"
    algorithm, other approaches might lead to a quicker resolution.

    One alternative is a "printf" approach to narrowing down the problem.
    Just as we often tell people to check that variables are what they
    think they are (D'oh! -- forgot to set an outlet), it might help if we
    state the relevant logic in *very fundamental* terms and have Johnny
    indicate *at which point* in the logic he gets lost.  This is the
    approach I tried to take earlier, and although Johnny referred to a
    line in the Apple docs rather than in my explanation, it led to a very
    revealing question.  He asked:

    > What other objects outside the nib?

    To me this suggested a FUNDAMENTAL disconnect, possibly at a level
    that precedes understanding File's Owner.  If I were inclined to
    follow up, I might ask:

    * Do you now understand there can be objects outside the nib?
    * Do you understand that your application creates objects, including
    the application instance, *before* loading MainMenu.nib?
    * Do you understand that you might want to create and load a nib other
    than MainMenu.nib?
    * Do you understand that you may have an object X of your own in your
    application just *before* you load your nib?
    * Do you understand that loading the nib will create a bunch of new
    objects A, B, and C?
    * Can you imagine that you'd want X to connect to one or more of A, B,
    and C?

    Besides the "printf" approach, another possibility might be a
    "homework" approach: write an application that does X, where X
    highlights the reason for File's Owner.  This would require extensive
    personal followup -- perhaps something a tutor could offer to do for
    pay.

    >> This is not magic - there is actual computer code behind that
    >> File's Owner concept, and it is deterministic, not vague, not
    >> abstract, not a philosophical enigma, not random, not ambiguous. If
    >> I had the source code I could see what it does.
    >>
    > But that's where you're leading yourself astray -- there isn't any
    > source code to see.  The nib file is an object graph with a hole in
    > it.

    I assumed Johnny meant the source code that *reads* the nib.  I
    personally don't believe that would help.

    > The File's Owner is the hole -- the one thing that *isn't* created
    > in the nib.

    First Responder and Application are also not created in the nib.  :)

    >> Despite teaching OB/GYN for 17 years, this is why computer science
    >> is always my main interest.
    >>
    >
    > Perhaps it's your background that's causing you the problem.  My
    > father was Dr. J. Selwyn Crawford.  I persuaded him to buy a Mac in
    > 1986.  He somehow failed to understand (a rarity) that when you use
    > a word processor you don't have to put Returns at the end of the
    > line...

    It's true we all have different blind spots.

    >> I've written firmware before we called it firmware. I have never
    >> NOT been able to grasp something until this and bindings. Aaron
    >> says lots of people have trouble understanding File's Owner, so I
    >> can only conclude that it's the documentation, or lack thereof.
    >
    >>
    > I think this is a fallacious conclusion.

    It is a fallacious conclusion for many reasons, one of which is that
    it also discounts the many sincere efforts of people on this list who
    have tried to help.

    --Andy

    [1] BTW, I am aware of the dangers of using computer concepts as
    models for human reasoning and human interactions.  Take this analogy
    only for what it's worth.
  • LOL - all of what you just described was the hair-pulling extravaganza
    that led me to a more detailed look at File's Owner in the first
    place. Several weeks ago I was trying to get my model object out of
    the nib, or more specifically, to figure out how to connect the
    controller to it if there was no nib NSObject that had the Class
    Identity of the class that contained my Model objects.

    I thought - aha, maybe this is what File's Owner is for, BECAUSE...
    you see many tutorials and examples of Cocoa Bindings where the author
    tells the reader to connect something to File's Owner. I thought maybe
    if you bind to File's Owner, it knows about all the keys in all of the
    objects in all of the classes of the app, so that you could just use
    File's Owner as the controller that the View object bound to, and
    write aClass.aKey as the Model Key Path.

    I have since realized that I need to just make a separate class for
    the model objects in Xcode (what I was doing, without realizing it,
    was having my one class actually be the app controller as well as the
    Model). Then just flat-out explicitly instantiate that class in the
    App Controller code. Now I have a name for the Model class' instance.

    Then in the bindings for my View Object, I can bind it to my
    NSArrayController's "selection" binding and set the model key path to
    myModelInstance.myModelKeyName.

    Took about a month of 16-hour days to get that down.

    On May 25, 2008, at 5:58 AM, <cocoa-dev-request...> wrote:

    > I know this is a bit silly, for a singleton like that you may as well
    > just put the model in there, but I'm trying to figure out if you
    > didn't, what the right way to hook it up to the controller is later.
  • On May 25, 2008, at 6:31 AM, Andy Lee wrote:

    >> The File's Owner is the hole -- the one thing that *isn't* created
    >> in the nib.
    > First Responder and Application are also not created in the nib.  :)
    >
    Indeed, that's why I didn't sleep so well -- something was nagging as
    I clicked Send just before dozing off, but I couldn't stay awake any
    longer to figure it out...
    (Although perhaps I've also got a little too used to looking at a
    different sort of nib file over the last couple of months...)
    That and the memory management errors in the code:

    - (void)createNibForWindowWithButton:(NSString *)fileName {

    // ...
    [NSKeyedArchiver archiveRootObject:nib toFile:fileName];
    [aWindow release];
    [aButton release];
    }

    > I hesitate to re-enter this thread, I really do.  But I think those
    > of us who have been trying to help might want to re-consider how
    > we've been answering, as well as how the questions have been posed.
    > There have been many fine, thorough answers to Johnny's question.
    > The fact that none of them have seemed to help should tell us
    > something.
    >
    That's a fair comment, but I'd nevertheless be interested to know if
    the code-based "explanation" helped (Johnny or anyone else).

    mmalc
  • On May 25, 2008, at 9:13 AM, Johnny Lundy wrote:

    > Took about a month of 16-hour days to get that down.
    >
    Experience suggests that this is a suboptimal way to try to learn Cocoa.
    Some concepts are better understood after quiet reflection.
    If you're struggling with a concept, find something else constructive
    to do for a while -- or just go and have a cup of tea -- then come
    back to it.

    mmalc

    (This email sponsored by R. Twining & Co Limited.)
  • On May 25, 2008, at 1:22 PM, mmalc crawford wrote:
    > On May 25, 2008, at 9:13 AM, Johnny Lundy wrote:
    >
    >> Took about a month of 16-hour days to get that down.
    >>
    > Experience suggests that this is a suboptimal way to try to learn
    > Cocoa.

    Early in his book, Aaron Hillegass suggests ten hours of sleep a night
    when you're learning something new, which I found one of the most
    interesting suggestions a programming book had ever made.  I keep
    forgetting to try it, though.

    --Andy
  • On May 25, 2008, at 10:30 AM, Andy Lee wrote:

    > Early in his book, Aaron Hillegass suggests ten hours of sleep a
    > night when you're learning something new, which I found one of the
    > most interesting suggestions a programming book had ever made.
    >
    Oh, in the Cocoa training courses we typically recommended that people
    don't work *too* hard.
    I try to make sure that people actually do take breaks during a
    course.  "Step away from the keyboard; stand up, stretch, do something
    else for a while."

    mmalc
  • On Sun, May 25, 2008 at 2:31 PM, Andy Lee <aglee...> wrote:

    > If I can make a rough analogy, many of our answers have been like different
    > re-implementations of an algorithm.  Like the guy on the guillotine in that
    > engineer joke, we each think we see what the problem is.  And so we "recode"
    > the algorithm our own way, "run" it -- i.e., post our new, improved
    > explanation -- and find it still fails. [1]

    What this thread has reminded me of is an ongoing conversation I have
    with a friend of mine, who refuses to countenance the square root of
    minus one, because he doesn't think it means anything. I explain to
    him how useful it can be to admit complex numbers for various
    real-world situations, but because there exists an algorithm to
    generate mandelbrots which doesn't ever do sqrt(n) for n<0, he thinks
    this proves that complex numbers are entirely unnecessary and
    therefore best avoided.

    It doesn't matter how much you explain that "real" numbers are
    imaginary too, or that the square root of 4 apples is also meaningless
    in a physical sense. He has a sort of emotional investment in the
    uselessness of complex numbers that completely blinkers him. The
    difference is, I doubt that this particular friend will ever have
    reason to do anything that will be made easier by using complex
    numbers, so I don't suppose his opinion will ever change. But I'm
    hoping that it's just a matter of time for Johnny.

    (Maybe when he has occasion to create a document-based app it will
    become clearer? Although bags I not the one to tell him that
    NSDocumentController is not designed to mediate between his view and
    his NSDocument ;] )

    Hamish
  • Thanks to everyone who replied and supplied sample code and anecdotes.

    I will study these carefully and take notes.

    N.B. My 16 hours a day comment did not imply that I am losing sleep. I
    really have been reading and adding features to my project, and
    creating dozens of test projects, and loading and studying dozens of
    sample projects, all day since April 1. I have nothing else to do
    except my annual board certification in OB/GYN and I am
    procrastinating on that. I do take a few minutes off to watch the News
    Hour, mow the lawn, and post at Apple.
  • Forgot one thing.

    If anyone would be interested to critique my whole project, I would
    appreciate it.

    It on my iDisk "johnnylundy", a zip file named "MafiaC9Arrays.zip"
  • On 25 May '08, at 11:58 AM, Hamish Allan wrote:

    > What this thread has reminded me of is an ongoing conversation I have
    > with a friend of mine, who refuses to countenance the square root of
    > minus one, because he doesn't think it means anything.

    It also reminded me of the fact that Isaac Asimov never managed to
    learn calculus; he said it seemed like some conceptual wall he
    couldn't get over. Didn't stop him from getting a Ph.D in
    biochemistry, inventing thiotimoline and positronic AI, and writing a
    few hundred books on science...

    I hit a similar wall in number theory, trying to understand finite
    fields. I managed to visualize how they worked for an hour or two
    while working on a homework set, but lost it after that, like some
    ecstatic vision of Heaven shown to a mystic, which he can never
    remember the details of afterwards.

    In my case I dropped the class, and later my math major*. I hope that
    doesn't sound too discouraging. I somehow found plenty of interesting
    things to work on that didn't involve bijective isomorphisms of finite
    abelian groups.

    I don't know what to suggest, Jonny ... I think we've all hit the
    limits of how vigorously we can wave our hands about the concept in an
    email thread. Taking a break from it would be a good idea, for all of
    us.

    —Jens

    * to be honest, the math major dropped me. I was kind of crushed,
    actually. But she later saw the error of her ways, though I eventually
    married an astronomer.
  • On May 25, 2008, at 1:30 PM, Andy Lee wrote:

    > Early in his book, Aaron Hillegass suggests ten hours of sleep a
    > night when you're learning something new

    Given my commitment to lifelong learning, that is now my official
    excuse for sleeping in late. :-)

    sherm--
  • On May 25, 2008, at 12:02 PM, Hamish Allan wrote:

    > What this thread has reminded me of is an ongoing conversation I have
    > with a friend of mine, who refuses to countenance the square root of
    > minus one, because he doesn't think it means anything. I explain to
    > him how useful it can be to admit complex numbers for various
    > real-world situations, but because there exists an algorithm to
    > generate mandelbrots which doesn't ever do sqrt(n) for n<0, he thinks
    > this proves that complex numbers are entirely unnecessary and
    > therefore best avoided.
    >
    > It doesn't matter how much you explain that "real" numbers are
    > imaginary too, or that the square root of 4 apples is also meaningless
    > in a physical sense. He has a sort of emotional investment in the
    > uselessness of complex numbers that completely blinkers him. The
    > difference is, I doubt that this particular friend will ever have
    > reason to do anything that will be made easier by using complex
    > numbers, so I don't suppose his opinion will ever change. But I'm
    > hoping that it's just a matter of time for Johnny.
    >
    > (Maybe when he has occasion to create a document-based app it will
    > become clearer? Although bags I not the one to tell him that
    > NSDocumentController is not designed to mediate between his view and
    > his NSDocument ;] )

    The way I look at it,  when you are attempting to learn a new subject
    you need to be humble. By that I mean you need to jettison some
    preconceived ideas and probably accept some things without a complete
    understanding (at least initially).  If you are not willing to do
    that,  you will have a hard time assimilating new ideas.

    Case in point, when I first started taking courses in electrical
    engineering, I remember some people saying that if you had previous
    experience with electronics/radio (like for example, you were a Ham
    radio operator), you might have more difficulty learning some concepts
    because you had preconceived ideas that were incorrect. (By the way,
    electrical engineering is where you will use complex numbers.)

    More to the subject at hand, I thought File's owner was just a
    mechanism for connecting nib objects to code. Nothing more or less. If
    I'm missing something, someone can correct me.

    Jim
  • On Sun, May 25, 2008 at 4:14 PM, James Merkel <jmerkel2...> wrote:
    > More to the subject at hand, I thought File's owner was just a mechanism for
    > connecting nib objects to code. Nothing more or less. If I'm missing
    > something, someone can correct me.

    Pretty much.  Any further significance is derived from the situation
    in which it's used.  For example, if you're using the default,
    AppKit-provided NSWindowController in your document-based application,
    the fact that the File's Owner is your NSDocument is an attribute of
    the arrangement you're working with.  But if you want to use your own
    NSWindowController, often times you'll make the owner of the NIB the
    NSWindowController itself, and if you need to get to the document you
    can do so by going backwards through the NSWindowController subclass.

    That might be why people are getting confused, actually.  File's Owner
    is just a slot, but it's always presented in a meaningful context, so
    people start attaching meanings to the concept that are really
    separate.

    --Kyle Sluder
  • Look at the other Currency Converter example (the non bindings one)

    http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/01In
    troduction/chapter_1_section_1.html


    this uses almost the exact same structure you're looking to implement.

    On May 25, 2008, at 5:01 AM, Roland King wrote:

    > Imagine that I have a model with two properties, number and its
    > square, something much like the currency converter. Ok I've written
    > my model object, it generates events when things change so if you
    > set the number, it computes the square and tells anyone listening
    > about it.
    >
    > View is easy - I have two text boxes.
    >
    > Then I write a controller which has outlets for the two text boxes,
    > and connections to the view so it knows when the text boxes update,
    > and it is able to set properties on a model, and listen to the
    > events on the model. ie lots of glue code.
    >
    > So the idea is I type a number in the text box, the controller gets
    > notified of the change, gets the number, sets the property on the
    > model. The model computes the square and notifies anyone listening
    > that it changed, the controller is listening, sees the change, gets
    > the new square and sets the text box on the view.
    >
    > That's my setup . So now I put the view and the controller in the
    > NIB and I don't instantiate a model object in the NIB because I want
    > to do that in code. This is a standard non-document application.
  • Am 23.05.2008 um 20:49 schrieb Johnny Lundy:
    > As usual, I can recite the documentation without understanding it :
    > File's Owner is a proxy object that is set at nib load time to the
    > object that loaded the nib (I don't know what object loaded my nib,
    > so that does not help me).

      OI presume you've used other programming languages, maybe even
    Carbon, where NIBs are also used? Well, in case you haven't, NIBs are
    essentially "freeze-dried" object hierarchies. They describe a part of
    a hierarchy, their objects and their various connections. To load
    them, you usually have an object, one of the various MVC-controllers
    (not necessarily NSControllers, just any NSObject subclass that
    behaves as a controller as in the "Model-View-Controller" paradigm).
    This object (usually called the owner of that NIB) has a method
    somewhere that calls NSNibLoading to actually load the NIB file and
    create objects from the description inside it.

      This object must exist *before* the NIB is loaded, so it can not be
    created by the NIB (can't be a blue box you drag out of the Library),
    and can not be in the NIB. However, often objects inside the NIB want
    to talk to the owner, so they added the File's Owner icon, which
    stands in for whatever object loads the NIB. Since NIBs are kinda
    generic, and don't know for sure who loads them until runtime, IB uses
    whatever class you specify as the class identity for File's Owner to
    decide what connections to offer you.

      Unless you write your own class that loads a NIB, you'll generally
    deal only with MainMenu.nib, which gets loaded by NSApplication (so
    the class identity is NSApplication) and a few others, like
    NSDocument, NSWindowController and NSViewController.

    > In MainMenu.nib, this is the application instance, which is a shared
    > singleton instance of NSApplication (how all applications can share
    > this is beyond me),

      Nobody said it was shared across processes. Shared in this instance
    means it is shared by everyone in the application's process, including
    any libraries and plugins you load.

    > which is also set to the global variable NSApp (uhh, OK...).

      This is probably more comprehensible if you think of it the other
    way round: There is a global variable called "NSApp" which contains a
    pointer to the NSApplication singleton. That way, you can call [NSApp
    launchedApplications] instead of [[NSApplication sharedApplication]
    launchedApplications]. Saves some typing and a method call, but isn't
    good for much else.

    > That's all well and good, but what exactly is this thing? Why would
    > I succeed in having an outlet in my class if I set the Class
    > Identity of File's Owner to my custom class? Why should I set File's
    > Owner's Class Identity rather than the Class Identity of a plain
    > NSObject that I drag out of the Library in IB?

      If you drag in a plain NSObject, that means it will create a *new*
    instance. Consider you already have an object of class NSApplication
    when you load the NIB. Dragging in an NSObject and settng its custom
    class to NSApplication would mean that, when that NIB is loaded,
    NSNibLoading would try to create a new object of that class -- in this
    case, you'd have *two* application objects -- which is definitely not
    what you want.

      BTW -- IB 3.x also added a proxy icon for the application. In
    MainMenu.nib, this means that whether you bind/connect to the File's
    Owner proxy icon or the application proxy icon won't make a
    difference. However, in an NSDocument's NIB, File's Owner will be set
    to the NSDocument, and the application proxy will still point to the
    application.

    Cheers,
    -- Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • Am 24.05.2008 um 04:58 schrieb Andy Lee:
    > As it turns out, you can do what you just described perfectly well
    > without using File's Owner and your application will be just fine.
    > The reason is that when your nib file was loaded, your window was
    > instantiated (remember that your window is one of the objects
    > described in the nib file), and when a window is instantiated it's
    > automatically added to the application instance's window list.  So
    > this is actually another connection between an object outside the
    > nib (the application instance) and objects in the nib (your window
    > or windows) -- a connection that is made for you that doesn't
    > require use of File's Owner.  None of us thought to mention this
    > connection (that I recall), because we were focused on the general
    > explanation of File's Owner.

      Err... I'm not sure if we're confusing the OP here by piling on more
    and more information not immediately relevant, but here goes a little
    clarification for the above point: The reason the above works is that
    NSApp is a singleton. So, what somebody is probably doing is taking
    advantage of its global scope and just accessing it directly. The
    File's Owner is here, because NIBs can be used in many other cases
    (which I mentioned before), and in most of those cases the owner is
    not a singleton. Quite the opposite, in fact:

      When you open a new file in an NSDocument-based app, NSApp creates a
    new NSDocument(-subclass) object for each file, and each loads its own
    copy of the NIB. That way, you can have several windows in the app,
    all built using the same code, all created from the same blueprint in
    a NIB, but all showing different data (from different files).

    Cheers,
    -- Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • On May 26, 2008, at 00:54, Uli Kusterer wrote:

    > This object must exist *before* the NIB is loaded, so it can not be
    > created by the NIB (can't be a blue box you drag out of the
    > Library), and can not be in the NIB. However, often objects inside
    > the NIB want to talk to the owner, so they added the File's Owner
    > icon, which stands in for whatever object loads the NIB. Since NIBs
    > are kinda generic, and don't know for sure who loads them until
    > runtime, IB uses whatever class you specify as the class identity
    > for File's Owner to decide what connections to offer you.

    Except that in trying to reduce your explanations to essentials, I
    think you've strayed into inaccuracy. File's Owner isn't the object
    that loaded the nib, it's the object that the object that loaded the
    nib *says* is the owner.

    With regard to this thread in general, and *not* related to your
    explanation in particular, I'd like to suggest that there are two
    major barriers to comprehensibility for someone trying to understand
    File's Owner.

    -- First, although it's *called* "File's Owner", the concept isn't
    essentially about files or ownership. It's about connection
    (specifically, connecting an object defined outside the nib to the
    object graph defined inside the nib). Yes, in the usual cases
    (NSApplication, NSDocument, NSWindowController and NSViewController)
    there are some frameworks-provided ownership-like qualities when
    objects of those classes are used as File's Owner, but that's more
    convenience than essential-ness.

    Note, for example, in a document-based application created using the
    Xcode template, File's Owner of MyDocument.nib (which in spite of the
    name is essentially a window nib file) is a NSDocument, although (I
    assume, though I could be wrong) that the nib is actually loaded by
    the NSWindowController created by the NSDocument. And since the
    lifetimes of the objects loaded from the nib are controlled by the
    NSWindowController, it could stake a claim to being the owner of those
    objects, though not File's Owner. The NSDocument, though File's Owner,
    doesn't really own anything, in any useful sense.

    -- Second, saying that "File's Owner is the object specified as the
    owner when the nib is loaded" (as the documentation does) isn't very
    helpful to someone trying to come to grips with the concept, since
    unless your application becomes large or complex enough to need
    specialized (or highly factored) nib files, you're unlikely to *load*
    a nib yourself, in the sense of writing an invocation of
    'loadNibNamed:owner:'.

    For main menu nibs (using NSApplication), window nibs (using
    NSDocument or NSWindowController) and view nibs (using
    NSViewController), you don't specify File's Owner, you use the File's
    Owner that the controller class determines on your behalf. So, a
    newbie's first exposure to File's Owner suggests that there's a right
    answer to what File's Owner needs to be, but the documentation (along
    with quite a number of the explanations in this thread) insists that
    File's Owner can be whatever you want it to be. Unless you clear up
    that *apparent* contradiction first, you can lucidly explain File's
    Owner till you're blue in the face without shedding any light
    whatsoever.
  • > So, a newbie's first exposure to File's Owner suggests that there's
    > a right answer to what File's Owner needs to be, but the
    > documentation (along with quite a number of the explanations in this
    > thread) insists that File's Owner can be whatever you want it to be.
    > Unless you clear up that *apparent* contradiction first, you can
    > lucidly explain File's Owner till you're blue in the face without
    > shedding any light whatsoever.

    What about if everybody called it NibOwner instead ? Wouldn't that be
    a lot clearer?

    ( from discussions earlier on )

    > "Here's my simple-minded mental model of File's Owner.
    >
    > 1. A nib is a file. File's Owner is thus the nib's "owner". An owner
    > is any object that agrees to act as a manager for some other objects.
    >
    > 3. Inside the box, objects can only connect to each other - it's a
    > closed system, so they are useless to the outside world, unless you
    > have a "connector" or "opening" or "port" (pick your own metaphor)
    > into and out of the box. File's Owner is that opening."

    As a new developer I would have found that immediately more intuitive.
    If the first time i opened up Interface builder I had an Icon which
    allowed me to make connections to NibOwner. Using the term NibOwner is
    far less ambiguous. It also promotes the wider context in which there
    may be multiple nib files, or the fact the NibOwner can be re-assigned.

    When you hear "file's owner" it tends to infer something more rigid
    (like fixed in the filesystem). Like if the file's owner were the
    application Bundle, or the User account (strictly speaking a file's
    owner is actually a unix account name).

    With no other point of reference then using the files owner object
    seems irrelevant. Clicking on most of the tabs in the Inspector shows
    "Not applicable" and a stretch not to conclude that it is rather
    ambiguous object used infrequently for some niche purpose. Of course
    it isn't a niche object at all, but a rather important one. However a
    newbie who is learning Cocoa wont know that until they have read a
    whole host of convoluted explainations. So i have to agree entirely
    with these comment that it is a challenge to explain those words,
    which must be an artefact of old Project Builder days stretching back...

    Just to file a bug report with Apple:  "File's owner" --> "Nib owner".
    It gets my vote. Any objections ?

    Finally we have also got some very good descriptions here about how to
    make application code. Specifically the best way to partition the
    cocoa classes and  and connect them sensibly into a Model-View-
    Controller. For those already keeping up theres no need to read on...

    But this has proven to be a very useful dicussion so I would just like
    to summarize some of the high - points.

    >>>>
    >
    > " if you want to use your own
    > NSWindowController, often times you'll make the owner of the NIB the
    > NSWindowController itself, and if you need to get to the document you
    > can do so by going backwards through the NSWindowController subclass."
    >
    >>>>
    >
    > "I have since realized that I need to just make a separate class for
    > the model objects in Xcode (what I was doing, without realizing it,
    > was having my one class actually be the app controller as well as
    > the Model). Then just flat-out explicitly instantiate that class in
    > the App Controller code. Now I have a name for the Model class'
    > instance.
    >
    > Then in the bindings for my View Object, I can bind it to my
    > NSArrayController's "selection" binding and set the model key path
    > to myModelInstance.myModelKeyName.
    >
    > Took about a month of 16-hour days to get that down."
    >
    >>>>
    >
    > "Normally your model objects would be created in code that didn't
    > care about NIBs or any UI objects. Then you would have a few NIBs
    > that deal with different aspects of your application and they have
    > to access the shared model objects (shared amongst all NIBs). How
    > would the controllers in these NIBs access the model? Via one of the
    > proxy objects. Which one (Application or File's Owner) depends on
    > whether the model is a global resource or something specific like a
    > document. It also depends on the NIB and what it expects its owner
    > to be."
    >
    >>>>
    >
    > "In a real application of any substance you'd likely create your
    > model object dynamically (from saved data or a new state which you
    > intend to be able to save and load in the future).
    >
    > In this _specific_ example (which is what that last sentence says)
    > the model object is being instantiated in the nib. This is because
    > the creation of the model object isn't what the example is
    > attempting to show... it's the connections between the objects and
    > creating them in IB."
    >
    >>>>
    >
    >> My NSArrayControllers can be bound to model objects without
    >> anything going through File's Owner.
    >
    > "Really?  That implies that your model is contained within the nib,
    > which is not how MVC is supposed to work.  The nib should contain
    > the V (View) and possibly C (Controller) parts of MVC, but it should
    > not contain the M (Model).  One of the points of separating Model
    > from View from Controller is that you can have multiple different
    > views on the same model.  Imagine an application which represents a
    > set of numbers in one window in a table and in another window in a
    > graph.  These two windows can (and probably should) be described in
    > separate nibs, and the model should live in neither.  It should be
    > instantiated in code somewhere else in your application, or managed
    > with Core Data, etc.  File's Owner would be needed to connect the
    > views and controllers in the nibs to the model."
  • Am 26.05.2008 um 19:49 Uhr schrieb Quincey Morris:

    > -- First, although it's *called* "File's Owner", the concept isn't
    > essentially about files or ownership.

    I guess that depends on your definition of "ownership". And we could
    argue wether an object graph loaded from a nib is still somehow
    attached to the original file. But I don't think that would be of any
    help in understanding the concept.

    > -- Second, saying that "File's Owner is the object specified as the
    > owner when the nib is loaded" (as the documentation does) isn't very
    > helpful to someone trying to come to grips with the concept,

    Maybe. But it's simply the definition of the term, so it *has* to be
    written like this.

    Really, that's all the File's Owner *is*: The object that was passed
    in as such when the nib was loaded.
    Everything else is interpretation, best practice, conventions etc.

    > So, a newbie's first exposure to File's Owner suggests that there's
    > a right answer to what File's Owner needs to be,

    Is that so? Well, that's a misconception. There's only examples of
    what *usually* is used as a File's Owner.

    > but the documentation (along with quite a number of the explanations
    > in this thread) insists that File's Owner can be whatever you want
    > it to be.

    Which is true.

    Andreas
  • > Just to file a bug report with Apple:  "File's owner" --> "Nib owner".
    > It gets my vote. Any objections ?

    It's been a long time since I first started learning this stuff, but I think
    that would have helped me at least a bit. In fact, last night I thought
    about making the suggestion.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.killerbytes.com/
    (303) 722-0567 voice
  • On Tue, May 27, 2008 at 2:24 AM, dream cat7 <dreamcat7...> wrote:

    > Just to file a bug report with Apple:  "File's owner" --> "Nib owner".
    > It gets my vote. Any objections ?

    The problem with "Nib owner" is that it suffers from exactly the same
    problem Quincey highlighted:

    "File's Owner isn't the object that loaded the nib, it's the object
    that the object that loaded the nib *says* is the owner. [...]
    although it's *called* 'File's Owner', the concept isn't essentially
    about files or ownership."

    "Nib owner" only fixes half of that problem.

    Perhaps "Nib's Delegate" would fit better with people's understanding?

    Hamish
  • On May 27, 2008, at 5:11 AM, Hamish Allan wrote:
    > The problem with "Nib owner" is that it suffers from exactly the same
    > problem Quincey highlighted:
    >
    > "File's Owner isn't the object that loaded the nib, it's the object
    > that the object that loaded the nib *says* is the owner. [...]
    > although it's *called* 'File's Owner', the concept isn't essentially
    > about files or ownership."
    >
    > "Nib owner" only fixes half of that problem.
    >
    > Perhaps "Nib's Delegate" would fit better with people's understanding?

    I think this would add confusion.  The File's Owner is not necessarily
    a delegate of anything, least of all the delegate of a nib.  The most
    common counterexample would be MainMenu.nib.

    If I could go back in time, I would address Quincey's observation like
    this:

      * Make +[NSBundle loadNibNamed:owner:] a *private* method.
      * Add an instance method on NSObject called loadNibNamed:, possibly
    in a category with a name like "Bundle Extensions"; it would call +
    [NSBundle _loadNibNamed:owner:].
      * Change the term "File's Owner" to "Nib Loader".

    This way we'd be reinforcing the concept of "load a nib" in two
    places, rather than "load a nib" in one place and "own a file" in the
    other.

    I don't know if there's too much existing stuff out there (code,
    documentation, third-party books, ingrained habits in people's minds)
    for Apple to change terminology this basic, or if it would be worth
    it.  But if it's possible and desirable that's how I'd suggest doing it.

    --Andy
  • On May 27, 2008, at 8:34 AM, Andy Lee wrote:
    > * Add an instance method on NSObject called loadNibNamed:, possibly
    > in a category with a name like "Bundle Extensions"; it would call +
    > [NSBundle _loadNibNamed:owner:].

    I just noticed +loadNibNamed:owner: is actually in a category of
    NSBundle added by AppKit.  So I'd amend the above as follows: -
    [NSObject loadNibNamed:] would be added to NSObject by a category in
    AppKit, and would be documented on a page with a title like
    "Application Kit Extensions".

    --Andy
  • On Tue, May 27, 2008 at 8:48 AM, Andy Lee <aglee...> wrote:
    > I just noticed +loadNibNamed:owner: is actually in a category of NSBundle
    > added by AppKit.  So I'd amend the above as follows: -[NSObject
    > loadNibNamed:] would be added to NSObject by a category in AppKit, and would
    > be documented on a page with a title like "Application Kit Extensions".

    Woah... so sending NSBundle a -loadNibNamed: message would make the
    NSBundle the File's Owner of the NIB?  Who would you send the message
    to?  This seems like a bad idea.

    --Kyle Sluder
  • On May 27, 2008, at 9:52 AM, Kyle Sluder wrote:
    > On Tue, May 27, 2008 at 8:48 AM, Andy Lee <aglee...> wrote:
    >> I just noticed +loadNibNamed:owner: is actually in a category of
    >> NSBundle
    >> added by AppKit.  So I'd amend the above as follows: -[NSObject
    >> loadNibNamed:] would be added to NSObject by a category in AppKit,
    >> and would
    >> be documented on a page with a title like "Application Kit
    >> Extensions".
    >
    > Woah... so sending NSBundle a -loadNibNamed: message would make the
    > NSBundle the File's Owner of the NIB?  Who would you send the message
    > to?  This seems like a bad idea.

    You would send the message to the object you want to be the File's
    Owner.

    Instead of:

        BOOL didLoad = [NSBundle loadNibNamed:@"MyNib" owner:myObject];

    ...you would say:

        BOOL didLoad = [myObject loadNibNamed:@"MyNib"];

    ...thus leaving out any mention of bundles as an implementation
    detail.  It would then be correct to say that the File's Owner would
    be the object that loaded the nib.

    --Andy
  • On 27 May 2008, at 15:06, Andy Lee wrote:

    > On May 27, 2008, at 9:52 AM, Kyle Sluder wrote:
    >> On Tue, May 27, 2008 at 8:48 AM, Andy Lee <aglee...> wrote:
    >>> I just noticed +loadNibNamed:owner: is actually in a category of
    >>> NSBundle
    >>> added by AppKit.  So I'd amend the above as follows: -[NSObject
    >>> loadNibNamed:] would be added to NSObject by a category in AppKit,
    >>> and would
    >>> be documented on a page with a title like "Application Kit
    >>> Extensions".
    >>
    >> Woah... so sending NSBundle a -loadNibNamed: message would make the
    >> NSBundle the File's Owner of the NIB?  Who would you send the message
    >> to?  This seems like a bad idea.
    >
    > You would send the message to the object you want to be the File's
    > Owner.
    >
    > Instead of:
    >
    > BOOL didLoad = [NSBundle loadNibNamed:@"MyNib" owner:myObject];
    >
    > ...you would say:
    >
    > BOOL didLoad = [myObject loadNibNamed:@"MyNib"];
    >
    > ...thus leaving out any mention of bundles as an implementation
    > detail.  It would then be correct to say that the File's Owner would
    > be the object that loaded the nib.

    And then how would you know where to find the nib in question? :)

    >
    >
    > --Andy
  • On May 27, 2008, at 11:51 AM, Mike Abdullah wrote:
    > On 27 May 2008, at 15:06, Andy Lee wrote:
    >
    >> On May 27, 2008, at 9:52 AM, Kyle Sluder wrote:
    >>> On Tue, May 27, 2008 at 8:48 AM, Andy Lee <aglee...> wrote:
    >>>> I just noticed +loadNibNamed:owner: is actually in a category of
    >>>> NSBundle
    >>>> added by AppKit.  So I'd amend the above as follows: -[NSObject
    >>>> loadNibNamed:] would be added to NSObject by a category in
    >>>> AppKit, and would
    >>>> be documented on a page with a title like "Application Kit
    >>>> Extensions".
    >>>
    >>> Woah... so sending NSBundle a -loadNibNamed: message would make the
    >>> NSBundle the File's Owner of the NIB?  Who would you send the
    >>> message
    >>> to?  This seems like a bad idea.
    >>
    >> You would send the message to the object you want to be the File's
    >> Owner.
    >>
    >> Instead of:
    >>
    >> BOOL didLoad = [NSBundle loadNibNamed:@"MyNib" owner:myObject];
    >>
    >> ...you would say:
    >>
    >> BOOL didLoad = [myObject loadNibNamed:@"MyNib"];
    >>
    >> ...thus leaving out any mention of bundles as an implementation
    >> detail.  It would then be correct to say that the File's Owner
    >> would be the object that loaded the nib.
    >
    > And then how would you know where to find the nib in question? :)

    I guess I am reinforcing the argument that one needs code samples to
    express oneself. :)

    You can add -loadNibNamed: to NSObject yourself, right now:

    - (BOOL)loadNibNamed:(NSString *)aNibName
    {
        return [NSBundle loadNibNamed:aNibName owner:self];
    }

    This would use the logic that +loadNibNamed:owner: uses for deciding
    what bundle to look for the nib in (see the docs for the method).  If
    you want more control over what bundle is used, you could write an
    NSObject method that wraps around -[NSBundle
    loadNibFile:externalNameTable:withZone:].  I leave that as an exercise
    for the reader.

    --Andy
  • On May 27, 2008, at 02:11, Hamish Allan wrote:

    > Perhaps "Nib's Delegate" would fit better with people's understanding?

    The counter-argument would be that "delegate" isn't the right word
    either, given that it has a specific meaning in Cocoa, and this isn't
    a delegate in that sense.

    Thinking about the conceptual issue again, it occurred to me that a
    word like "owner" (and "delegate", I think) may suggest -- to someone
    trying to come to grips with the concept -- that File's Owner must
    have some *behavior* that qualifies it to be an owner, whereas there
    are no behavioral requirements at all. To be qualified to be used as
    File's Owner, all an object needs is some outlets to connect into the
    nib object graph and/or some observable properties that objects in the
    nib can bind to.

    For example, as I said before, you can use a NSDocument subclass as
    File's Owner of a window nib file, but it's the document's
    NSWindowController (afaik in this case) that has the behavior that
    loads the nib and manages the lifetime of the objects in the nib. The
    NSDocument has no knowledge of the nib (again, afaik) -- beyond its
    blind passing of the nib name to its window controller.

    So I was wondering if something like "Nib's Root Object" might work
    better. I think, to anyone with even a small amount of exposure to
    programming topics, "root" connotes something structural and not
    something behavioral, which seems appropriate here.

    On May 27, 2008, at 07:06, Andy Lee wrote:

    > You would send the message to the object you want to be the File's
    > Owner.
    >
    > Instead of:
    >
    > BOOL didLoad = [NSBundle loadNibNamed:@"MyNib" owner:myObject];
    >
    > ...you would say:
    >
    > BOOL didLoad = [myObject loadNibNamed:@"MyNib"];
    >
    > ...thus leaving out any mention of bundles as an implementation
    > detail.  It would then be correct to say that the File's Owner would
    > be the object that loaded the nib.

    Aside from functional issues, I'm not sure this helps greatly on the
    conceptual front. It may just shift the question from "Which object do
    I specify for 'owner:'?" to "Which object do I send the message to?" I
    guess you'd have to test it in the field to find out. :)
  • On May 27, 2008, at 2:02 PM, Quincey Morris wrote:
    > So I was wondering if something like "Nib's Root Object" might work
    > better. I think, to anyone with even a small amount of exposure to
    > programming topics, "root" connotes something structural and not
    > something behavioral, which seems appropriate here.

    That's not good either.  "Root object" has a special meaning in the
    context of archiving graphs of objects.  In particular, it's one of
    the archived objects, whereas File's Owner is by definition not one of
    the objects in the nib.

    > On May 27, 2008, at 07:06, Andy Lee wrote:
    >
    >> You would send the message to the object you want to be the File's
    >> Owner.
    >>
    >> Instead of:
    >>
    >> BOOL didLoad = [NSBundle loadNibNamed:@"MyNib" owner:myObject];
    >>
    >> ...you would say:
    >>
    >> BOOL didLoad = [myObject loadNibNamed:@"MyNib"];
    >>
    >> ...thus leaving out any mention of bundles as an implementation
    >> detail.  It would then be correct to say that the File's Owner
    >> would be the object that loaded the nib.
    >
    > Aside from functional issues, I'm not sure this helps greatly on the
    > conceptual front. It may just shift the question from "Which object
    > do I specify for 'owner:'?" to "Which object do I send the message
    > to?" I guess you'd have to test it in the field to find out. :)

    I was addressing specifically the point you made, which was that
    "File's Owner isn't the object that loaded the nib, it's the object
    that the object that loaded the nib *says* is the owner."  My way,
    this level of indirection goes away.

    If you look at the rest of my original suggestion (before the
    clarification above), I suggested the term "Nib's Loader" as a
    replacement for "File's Owner", which would connote something
    behavioral: "I'm the object that loaded this nib."

    I think "Nib's Loader" would have decreased cognitive load if it had
    been the term used in the first place (along with the -loadNibNamed:
    change).  I wrote:

    > This way we'd be reinforcing the concept of "load a nib" in two
    > places, rather than "load a nib" in one place and "own a file" in
    > the other.

    I personally think this would help, mainly if we could go back in time
    to make the change ;).  But maybe it wouldn't.

    --Andy
  • On May 27, 2008, at 11:50, Andy Lee wrote:

    > That's not good either.  "Root object" has a special meaning in the
    > context of archiving graphs of objects.  In particular, it's one of
    > the archived objects, whereas File's Owner is by definition not one
    > of the objects in the nib.

    Yes.

    > I was addressing specifically the point you made, which was that
    > "File's Owner isn't the object that loaded the nib, it's the object
    > that the object that loaded the nib *says* is the owner."  My way,
    > this level of indirection goes away.
    >
    > If you look at the rest of my original suggestion (before the
    > clarification above), I suggested the term "Nib's Loader" as a
    > replacement for "File's Owner", which would connote something
    > behavioral: "I'm the object that loaded this nib."

    Yes, I agree it's simpler, but I really do think you'd need to test it
    out on some unsuspecting victims before you could be sure it was
    eliminating the part of the complexity that's actually causing the
    difficulty.

    Putting this the other way round, I'm not sure that the answer is to
    give File's Owner or Nib's Loader behavior that justifies its name,
    but rather to give it a unobjectionable name that justifies its (lack
    of) behavior -- if anyone can come up with such a name.
  • On May 27, 2008, at 3:40 PM, Quincey Morris wrote:
    > Putting this the other way round, I'm not sure that the answer is
    > to give File's Owner or Nib's Loader behavior that justifies its
    > name, but rather to give it a unobjectionable name that justifies
    > its (lack of) behavior -- if anyone can come up with such a name.

    "Connection Point" or "Nib Connection Point", maybe.

    The problem is that we're stuck with "owner" because it's used in the
    framework API (+[NSBundle loadNibNamed:owner:] is just one place
    where that terminology is embedded).

    Cheers,
    Ken
  • On May 27, 2008, at 4:40 PM, Quincey Morris wrote:
    > On May 27, 2008, at 11:50, Andy Lee wrote:
    >> If you look at the rest of my original suggestion (before the
    >> clarification above), I suggested the term "Nib's Loader" as a
    >> replacement for "File's Owner", which would connote something
    >> behavioral: "I'm the object that loaded this nib."
    >
    > Yes, I agree it's simpler, but I really do think you'd need to test
    > it out on some unsuspecting victims before you could be sure it was
    > eliminating the part of the complexity that's actually causing the
    > difficulty.
    >
    > Putting this the other way round, I'm not sure that the answer is to
    > give File's Owner or Nib's Loader behavior that justifies its name,
    > but rather to give it a unobjectionable name that justifies its
    > (lack of) behavior -- if anyone can come up with such a name.

    Beyond convenience, I think it makes sense conceptually to think of
    the owner as doing the loading.  But if the idea didn't jump out at
    you that way, maybe it wouldn't to other people either.

    Anyway, I doubt I'll accomplish much by pushing the idea further, so
    I'll back out of this thread too.

    --Andy
  • As one who has been on the Cocoa road slowly over the last year (not
    much in the middle, though), it has let me learn and absorb Cocoa
    terminology and ideas slowly. But the one thing I found weird was
    File's Owner. I knew what it meant. I knew what it does (and
    especially after this past week I think I know very very well), but
    the name throws me off mentally.

    I liked "Nib's Owner". It keeps with the "owner" tag, but makes it
    more clear.

    > On May 27, 2008, at 3:40 PM, Quincey Morris wrote:
    >> Putting this the other way round, I'm not sure that the answer is
    >> to give File's Owner or Nib's Loader behavior that justifies its
    >> name, but rather to give it a unobjectionable name that justifies
    >> its (lack of) behavior -- if anyone can come up with such a name.
    >
    > "Connection Point" or "Nib Connection Point", maybe.
    >
    > The problem is that we're stuck with "owner" because it's used in the
    > framework API (+[NSBundle loadNibNamed:owner:] is just one place
    > where that terminology is embedded).
    >
    > Cheers,
    > Ken

    Alex Kac - President and Founder
    Web Information Solutions, Inc. -  Central Texas Microsoft Certified
    Partner

    "It is useless for sheep to pass a resolution in favor of
    vegetarianism while wolves remain of a different opinion."
    -- William Randolph Inge
  • Alex Kac wrote:
    > I liked "Nib's Owner". It keeps with the "owner" tag, but makes it more
    > clear.

    True, but the use of NIB vs. File may be a historical set-in-stone thing
    that never changed since the NIB is the File (conceptually, of course,
    since a NIB is a directory with three files), and everyone early on knew
    that.

    And for anyone who might still be having issues with differentiating the
    loader of the NIB vs. the owner as assigned, a way to think of this is
    what happens in the real world when a person creates a company but
    assigns legal ownership of it to his/her child.  The creator of the
    company could have kept ownership, but through a deliberate decision,
    that ownership is transferred to the child.  And, as with all types of
    businesses, not all owners are involved in the same capacity (think of a
    mom-and-pop restaurant owner vs. Steve Jobs vs. Meg Ryan as a bookstore
    owner in You've Got Mail), so that's one way you might conceptualize the
    generality of File's Owner.
  • while the discussion of possible re-positioning of the term file's
    owner is interesting, discussing it here isn't going to change how it
    is referred to in the documentation (and for that matter, I doubt it'd
    be changed from file's owner anyways...)

    please take it off-list

    thanks

    scott
    [moderator]

    On May 27, 2008, at 4:47 PM, Ken Thomases wrote:

    > On May 27, 2008, at 3:40 PM, Quincey Morris wrote:
    >> Putting this the other way round, I'm not sure that the answer is
    >> to give File's Owner or Nib's Loader behavior that justifies its
    >> name, but rather to give it a unobjectionable name that justifies
    >> its (lack of) behavior -- if anyone can come up with such a name.
    >
    > "Connection Point" or "Nib Connection Point", maybe.
    >
    > The problem is that we're stuck with "owner" because it's used in
    > the framework API (+[NSBundle loadNibNamed:owner:] is just one place
    > where that terminology is embedded).
    >
previous month may 2008 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today