Re: [Pyobjc-dev] Wild idea #17: Extra functionality for NibClassBuilder

[Just v. R. <ju...@le...>]

Jack Jansen wrote:

> As a typical (well, somewhat typical) novice user there's one problem 
> that I keep running into with PyObjC: it is very difficult to 
> undeerstand code that comes from a third party.
> 
> For example, I'm now looking at iClass and Just's two browsers, and 
> while the code itself is minimal and pretty understandable it doesn't 
> really tell me all that much, because all the high-level "code", the 
> stuff that glues the world together, is really in the NIB file.

The nib is basically three things:
- some class definitions
- some object trees
- a set of connections between various objects within the nib

The nib file itself is pretty much analogous to a pickled object graph.

You get a real good overview if you view the nib in IB itself, in the
"Instances" tab, but set to "list view" (push the lower one of the two
tiny buttons above the vertical scroller in the main nib window. Click
on the funny arrows to find out which connections go where).

> Running NibClassBuilder from the command line helps a little bit, in
> that it at least tells me what the relevant classes are, but this
> isn't really enough, what I need to know are connections and such.

It would be nice if nibclassbuilder would have an option to print an
overview of classes/objects/connections, but I doubt it will be better
than what IB already offers.

> What then occurred to me is that all the action really occurs when
> awakefromnib is called (at least: I assume this is when it happens,
> correct?),

awakeFromNib, if defined, is called when the object has been
"unpickled", it's a callback that tells you the object is alive again. I
think it's called right after the object is unpickled, and not when the
entire object graph is ready, but I'm not entirely sure.

> and the info on what occurs is in the nib. So, we should
> be able to create a Python rendition of what will happen when
> awakeformnib happens. This would be only for documentary purposes,
> but the Python rendition would show the objects being created and the
> connections being made, something like (example taken from iClass):
> 
>   Window = NSWindow()
>   # Need code here to show the objects in the window and the names
>   # we use for them in this code
>   Window.item_NSTextField_0 = NSTextField() # Title: framework
>   Window.item_NSTextField_1 = NSTextField() # Pos: (309, 442, 397, 17)

[You're thinking too much in W terms ;-) Views that can contain subviews
simply have a list of (anonymous) subviews, accessible with
view.subviews(). You only name things you need to have access to, in the
form of an connected outlet, which is simply an ivar pointing to the
thing it's connected to. Btw, outlets (and delegates, datasources,
targets, etc.) are always weak references, in the Objective-C sense,
meaning it's a pointer that's not retained, *shudder*...]

>   # ...
>   MainMenu = NSMenu()
>   # ...
>   Model = ClassesDataSource()
>   Model.frameworkLabel = Window.item_NSTextField_1
>   # ...
> 
> Is this doable?

Maybe, but it's not what happens, AFAIK, as unpickling an object from a
nib is not done by instantiating it "as usual" (not at all unlike how
pickle works!). I'm not sure how the connections are made, as part of
the unpickling or as a separate step.

Just