• I'm saying I generate the nib bundle and its XML files
dynamically. And then load and run them (since 2003).
What does this get you that generating the object graph that
represents the user interface itself won't? Persistence? Or
something else?
What that gets me is an homogeneous continuity where the
specification travels through a unix script level thru it's interface
(which I do mostly in C++) thru CoreFoundation types thru OSA to a
Carbon venue handled by my code (and to a certain extant back the way
it came). Since I use Tcl to coordinate, namespace conventions are
happily exactly the same as in C++.
Objective-C is bereft of namespaces.
The choice of languages for the implementation of this product (an
OSA component suite supporting about 7 languages) was based on what
seemed most expedient for the situation. Cocoa is used in a few
places that are suitable, including a minimal web browser helper app.
What's not suitable for this project is an Objective-C/Cocoa approach
throughout. Otherwise, like I heard the guy who did the grunt work on
PyObjC, I'd be spending 10 years on it.
Using Cocoa you absolutely can generate a view hierarchy at
runtime, connect it to code, and use it. NSResponder (the immediate
superclass of NSView) also implements the NSCoding protocol, so you
can archive a view hierarchy for later unarchiving and reconnection.
Ok. But that doesn't make it useful for my situation.
Philip Aker
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
