Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Doug Scott <email@hidden>
- Date: Thu, 25 Jun 2009 09:35:39 -0700
On Jun 25, 2009, at 12:46 AM, Alexander Spohr wrote:
Am 25.06.2009 um 00:46 schrieb Doug Scott:
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.
This sounds like A and B should be one IB-Plugin?
No. Originally A and B were all combined into one view in an
application I wrote about six years ago. The application worked out
well enough but I immediately found I wanted to use the same general
functionality in another totally unrelated application that would need
to use two copies of B, thus the desire for C, and the desire to turn
all of the basic functionality into what was at the time a series of
IB palettes.
IBPlugin-A has basic capabilities that allow it to be used 'as is' if
that is all that is needed and can be code driven.
IBPlugin-B enhances the usability of IBPlugin-A vastly by allowing the
user to manipulate the controls to drive the state of IBPlugin-A.
IBPlugin-C is a specialized use needed only by Application-D which
wants to show data in IBPlugin-A from two sources simultaneously.
The most generally useful one is IBPlugin-B but I plan on using both
IBPlugin-A and IBPlugin-C elsewhere as well as needs warrant.
- IBPlugin-C: A view which embeds two IBPlugin-B views side by side.
And just throw C in as well.
Why do you have to have three plugins where it looks like you just
need one?
Been there, done that. See above.
Although I'm quite happy with the end results of being able to
utilize nested IBPlugins of ever encreasing complexity [...]
I am always unhappy if my code gets too complex. I often just take
some time to clean up my code. :)
This was the code cleanup. (|:->
And I'm actually very happy with the usability of the resulting
IBPlugins, particularly now, after having paid the overly heavy price
of figuring out how to make it all work. Apple gives us external
developers a huge amount of power in IBPlugin embedding, in that the
visual nib chain becomes very object oriented too, just like the code
chain can be. The IBPlugins just drop in to each other or into an
applications nib view and I just wire them up just like I do with
Apple's basic controls and they all 'just work'.
The complexity that makes me 'very' unhappy is the time it takes to
manually ripple a change through the usage chain during development.
Occasionally things reach a point where I'm not making changes and I
get to 'just use them' and they each work as designed and make my life
as a developer much easer. It is when I notice a misspelled word or an
errant pixel that I need to go back to IBPlugin-B to tweak things or
to add another control to expose yet another feature of IBPlugin-A
that overall Xcode build system falls apart ( in my opinion ) because
of IB design limitations.
Nib files seem to be only a static 'snapshot' of a point in time
during the development processes,
This is exactly what they are: Frozen objects.
And that is exactly why IB is a problem in an otherwise dynamic build
system. Development is a dynamic process and IB sees a big pile of
static nibs. In the code side of development I can just manually
navigate to a framework, select it, import it, write a bit of code to
interface with it and forget about it. If I then fix a bug in the
framework the Xcode build system picks it up and I'm not involved any
further, unless my change breaks the build.
The visual portion is often the most dynamic part of the development
cycle, at least from time to time, where I'm adding a control,
changing a color, changing the size of a text box and so forth, none
of which ripple though the build automatically, forcing me to 'pay the
price' of making what should be an extremely minor change in some
cases or an extremely large change when adding basic functionality in
other cases. The price is always the same no matter how small or large
the change.
If IB became a dynamic part of the Xcode build system I would just
drag & drop an object from project IBPlugin-X into project IBPlugin-Y
and have IB make the link ( and probably import the a true full copy
of the referenced object ). I would of course manually position the
referenced object ( once ), wire up its outlets ( once ) and forget
about it ( once and for all ), just like I do when I reference one of
my standard code-only frameworks.
IB would from then on monitor the link for changes to the referenced
object ( request a checksum? ) and silently re-import any changes and
re-wire the outlets identically so long as they remained unchanged
from the point of view of what IB needed to mess with. The position of
a view would be maintained too, but if its size changed or an outlet
was added, removed or renamed it would have do the best it could and
then issue a warning about things it couldn't deal with yet. If the
outer frame changed shape I'd then have to manually deal with it
again, just like I do when my code API changes in a framework and
breaks the build. Only when IB can do all of this will it become what
it should be, a dynamic part of a dynamic build system.
The need to import a true copy of the object into IBPlugin-Y is
because the referenced IBPlugin-X will probably become unreachable at
some time in the future and every IBPlugin should be able to be built
the way it currently is built - with the most recently imported and
now locally static information. It would also probably be a smaller
change to IB if the referenced object was just copied into the
internals of the nib and IB would return to its normal operations from
that point forward. If a link becomes unreachable IB should just
report the broken link and build the old copy, thus never breaking the
build and also reminding me to manually break the link if I no longer
want to maintain that relationship. I could even wire it up to a
different, perhaps experimental, version of IBPlugin-X to do testing
as I work on my overall projects. One drag, one drop, link changed, IB
wires it all up the same way to the same outlets or reports
incompatibilities for me to deal with and the build system ripples the
changes across all IBPlugins and all applications; exactly like the
code side figured out how to do way back in the previous millennia. No
magic needed to make it 'automagically' work. One change to IBPlugin-
X, hit the build button. 20 IBPlugins projects import the change, 5
applications pick up the changes as used in each of their 10 nib views
and all I have to do is test 5 applications when the massive build
completes. In the current state of affairs I'd have to manually do all
that change rippling up the chain and believe me, it is extremely time
consuming and error prone in just my single A, B, C, D chain. Turn it
into a large tree and there is no way to keep up with it. Thus my
reference to madness.
and not really part of a modern dynamic build system.
Why? Because they work different than code? They are different
because they are just data.
Did I miss your point somewhere?
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.
atze
_______________________________________________
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