On Thu, Jun 25, 2009 at 9:35 AM, Doug Scott<[email protected]> wrote:
> The point is that the way IB seems to work today is static when it must > become dynamic if developers are to be able to embed IBPlugins within each > other in the way I've done, which I've found to be incredibly powerful and > useful. It is just that in my own relatively simple experiments I have found > this technique to be incredibly difficult to maintain during development due > to its manual nature. Once I stop fiddling with things and my IBPlugins > becomes static again everything is fine, but during development it is > anything but static. Thus my query in the hopes that I missed something that > IB could do for me that I'm currently dealing with manually ( the hard way ) > and at great expense of time and sanity. Humm you appear to be using IB plugins to bag up pre-configured objects that you want shared across applications in a dynamic fashion (not what they are designed for). Normally IB plugins are intended to provide ways to add custom views (objects) and matching inspectors to configure those views (objects) not so much intended to do what I think you are trying to use it for. It sounds like you should instead create a xib/nid that contains the shared objects with a well defined file owner that can be shared across your applications. When you modify this xib/nib it will affect all applications that include the xib/nib. It is trivial to load nibs in code and stitch them into your runtime object graph. -Shawn _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
