Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Kevin Cathey <email@hidden>
- Date: Thu, 25 Jun 2009 10:36:16 -0700
Doug,
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 makes a good point here. IBPlugins exist to allow you to create
a custom view or object, write inspectors to make changes to your
objects and views in IB in real-time, and not have to write a bunch of
configuration code in awakeFromNib or windowDidLoad, etc. In some
cases, this is a much preferable workflow to dragging out a generic
NSView and setting its custom class to be your class, which would not
warrant the ability to manipulate your class directly in IB.
In the scenario you have described (with Plugin's A, B, and C), you
can certainly put all of that into a single plugin. In fact, much of
the Interface Builder library is a single plugin. This would probably
solve many of the problems you are seeing with the "changes not
getting updated" across plugins. I wouldn't worry too much about
having a plugin that is used in multiple applications. For example,
the IB library contains all of the buttons you might ever want to add
to your application, not just the ones you might use in a single
application. When you nib files get archived, only the controls you
use will get archived, not the contents of the entire plugin.
and not really part of a modern dynamic build system.
Interface Builder and nib files are actually more dynamic than you
might think. For example, when you load a nib file created 3 years ago
in a running application, the controls all have the behavior of the
current version of the OS. In addition, you can set the custom class
of any object in IB, and at runtime, that object assumes the custom
class you've set. A nib file simply stores the classes that your
objects will be at runtime, and the properties those objects wish to
archive for loading later on as key-value pairs. I think the reason
you are seeing issues across your plugins is that you are changing the
properties that get archived. For example, if you change a button's
title in Plugin B, you would have to update nibs in Plugin C because
Plugin C had archived that button's title to be something else. Again,
I believe making this all one plugin and framework would solve these
problems.
Kevin
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden