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

[Ronald O. <ous...@ci...>]

On Tuesday, Jun 10, 2003, at 17:34 Europe/Amsterdam, Just van Rossum 
wrote:

> 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.

Extactly. A major difference between a pickle and a NIB file is that 
the NIB loader will use attribute setter methods when these are 
available. This might be used to find the connections.

>
> 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).

I didn't know about this one, this is pretty usefull.

>
>> 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.

Such a beast might be usefull for examples posted on the web.

>
>> 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.

It is called when the entire object graph is connected, you get no 
guarantee on the order in which the various awakeFromNib methods are 
called.

>
>> 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*...]

The reason for this is probably that updating release counts is 
expensive. Not a very good reason if you ask me. Updating the release 
counts is relatively expensive because there is locking involved: ObjC 
has no GIL.

>
>>   # ...
>>   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.

It's probably doable, but wouldn't involve awakeFromNib. What happens 
when you load a nib is that the pickled views are restored after which 
the connections are restored. If you have setter-methods for your 
outlets these will be called.

The hard part is finding the orginal location/name of the widgets.

Ronald