Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Doug Scott <email@hidden>
- Date: Thu, 25 Jun 2009 11:39:24 -0700
On Jun 25, 2009, at 10:37 AM, Kevin Cathey wrote:
You should not under any circumstances modify a XIB file outside of
IB.
I don't even build the darned things. When they first came out they
messed up the build in ways I really didn't have time to figure out. I
just set things to build the old way only. Problem solved. Haven't
needed to revisit the issue. When it stops being broke I stop fixing it.
Kevin
On 24 Jun 2009, at 16:10, WT wrote:
Hi Doug,
I don't have any experience in designing and implementing IB
plugins, but I thought I'd pass along an observation that has
served me well on occasions when I needed to make error-prone
changes to many similar nib files (well, xib files, actually): xib
files are xml files, so they're amenable to text-editing.
If the changes you find yourself making are reasonably structured,
you could write a script that processes your plugin xib files and
add a run-script phase to your build system.
Wagner
On Jun 25, 2009, at 12:46 AM, Doug Scott wrote:
Question: How can I automate the maintenance of embedded IBPlugins.
Xcode Version 3.1.3
Interface Builder Version 3.1.2 (677)
I have developed a small series of custom IBPlugin framework
projects, two of which include other custom IBPlugin objects. Here
is a quick overview of the hierarchy.
- IBPlugin-A: A view with a custom API.
- IBPlugin-B: A view which adds a set of controls to manipulate
the embedded IBPlugin-A view via its API.
- IBPlugin-C: A view which embeds two IBPlugin-B views side by side.
- Application-D: Contains a nib with a view which contains an
IBPlugin-C view.
- Problem: Change is pure drudgery. When I make even the most
trivial change to IBPlugin-B I have a long string of manual 'fix-
ups' I must do to make everything once again function correctly in
Application-D.
- Solution of the moment: Think thrice before I make a change and
if it is 'worth it' go ahead and change it - then pay the price.
- The price: Details withheld for brevity. Suffice it to say there
is a lot of manual dragging and dropping and outlet connection
repairs and terminal install builds at each level up the chain of
IBPlugin frameworks and IBPlugin Librarys and nib views as old
custom view objects are deleted and new ones dropped into their
place and reconnected to their outlets. Miss one step somewhere
and nothing works - start over dude!
Although I'm quite happy with the end results of being able to
utilize nested IBPlugins of ever encreasing complexity I'm not at
all happy with the ever increasing complexity needed to manually
repair everything up the chain when I make a simple tweak to a
lower level custom IBPlugin. This problem appears to make future
expansion of embedded IBPlugins almost impossible to maintain as
I'd have to do the manual fix-ups to every future IBPlugin and
every application and every nib that used an IBPlugin that is
modified. This way lies madness.
In the realm of compiled code I simply 'include' a framework or
'import' external sources and it all gets picked up
'automagically' by all code that uses external code. But in the
'visual' world of Interface Builder it seems to require human
intervention at every step of the way. I do not see any way for
the different views to 'include' other views indirectly, only by
manually adding the objects via drag and drop can an IBPlugin be
upgraded to utilize another custom IBPlugin's visual elements. Nib
files seem to be only a static 'snapshot' of a point in time
during the development processes, and not really part of a modern
dynamic build system.
I'm hoping that I missed the point somewhere along the long and
painful journey I've travelled in my quest to pound IBPlugins into
submission and that wiser heads will be able to lead me to wisdom.
-Doug Scott
_______________________________________________
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
_______________________________________________
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