Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Kevin Cathey <email@hidden>
- Date: Thu, 25 Jun 2009 10:37:48 -0700
You should not under any circumstances modify a XIB file outside of IB.
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