Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Doug Scott <email@hidden>
- Date: Thu, 25 Jun 2009 11:33:56 -0700
On Jun 25, 2009, at 10:36 AM, Kevin Cathey wrote:
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.
Each of my IBPlugins contain an inspector, currently with no or only
limited functionality, but adequate to my current configuration needs.
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.
Perhaps, but even within a single IBPlugin if I change the primary
framework view object I have to manually drag it into the Library view
and fix up all the connections which are broken when I removed the
previous version of the Library view to make room for the new one. It
seems that I'd just be moving the ripple problem into a single
IBPlugin complex for little or no gain. Not good. If I don't do this
copy of the view object from the framework nib to the Library view the
Library object still contains the old version of the framework object
and the resulting build and install of the IBPlugin object in the IB
Library panel is unchanged and I have to go back and fix it and
rebuild it. Not good.
Perhaps there is something basically wrong in the way I'm making
IBPlugin projects, but based on the very few IBPlugin samples I have
seen and the fact that it all does eventually work fine in my
application I have maintained the same pattern. I couldn't get
anything to work until I had a framework view that the framework code
outlets deal with and this framework is what gets installed into the
applications bundle. It is the framework view that has to be manually
dragged into the Library view for it to appear correctly in the IB
Library panel. If I don't do it this way all I get is a rectangle
representing the view and no visual contents. Not good. My initial
query to the list was in the hope that perhaps someone might be able
to point me to the 'correct' way of building an IBPlugin if it turns
out that my way of doing it is silly. But at the end of the day it all
works fine, so I at least have found what I consider to be a valid way
to beat this thing into submission, silly or not.
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.
Over the years I've played around with several ways of dealing with
this and the way I now have it working is exactly the way I wanted it
to work years ago when I started out with IB palettes. Many moons ago
I was trying to deal with this embedding issue by using a place holder
view and loading the nib objects via code and swapping them into place
and wiring things up in code where necessary. It worked, but wasn't
something I could maintain and was visually crummy in IB.
This embedded IBPlugin thing is actually really, really exactly the
thing I was looking for. Real objects in the IB Library panel and a
real hierarchy of objects without imposing an unnatural container for
all of them on them, although in this case they happen to be a visual
family. If in the future I wanted to create another IBPlugin that was
just a button that when pressed played some weird sounds I might want
to use in in one of the current set of IBPlugin views but it wouldn't
have any reason to be part of the family.
It is just the static isolated nature of every IBPlugin that is the
killer in the long run.
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