IB Plugins, when to use, and GC?
IB Plugins, when to use, and GC?
- Subject: IB Plugins, when to use, and GC?
- From: Rick Hoge <email@hidden>
- Date: Sat, 2 Feb 2008 22:03:30 -0500
I'm resuming some experimentation I started a while back with IB
Plugins. In some of our projects we have view hierarchies, toolbars,
and context menus that are used in different nib files and which
contain elements which are time-consuming to lay out by hand. Some of
the interface elements that could be candidates for inclusion in an
IB Plugin also use custom classes. Right now I'm trying to work out a
few design/philosophical issues:
- our app is GC-only, so the fact that custom classes included in an
IB Plugin would need to have manual memory management support added is
a bit of a pain. It's especially annoying since, typically, none of
the functionality of these custom subclasses that requires any memory
management would actually be used within IB. For example, one of our
UI elements would include an NSImageView subclass with some added
methods and a few extra instance variables - none of which would be
invoked within IB to render the view or during simulation. The
motivation to include this class of view in an IB Plugin would be that
instances of this NSImageView subclass are typically used within a
nested view structure in which various parent views need to have a
very specific combination of configuration settings (all done through
IB Inspector checkboxes). I suppose I could just create the nested
view structure within the IB Plugin, leaving the class of the child
view as NSView (removing the need to include our class in the IB
Plugin framework and hence the need to support manual memory
management). Seems to be no problem to modify the class after
dragging the view hierarchy into a nib file from the custom IB
plugin. Is there any reason why this would not be valid or advisable?
- am I correct in concluding that the primary benefit offered by the
IB Plugin mechanism relates to re-use of layout and configuration
settings of graphical elements done within IB, and not so much to re-
use of the class logic (i.e. the source code)? It seems to me that I
could share the UI layout in an IB Plugin, and the class code via a
separate framework (not an IB Plugin) and avoid the problem of having
to support two modes of memory management in the code. With this
approach I *would* have to assign classes and connect any IB outlets
manually, but if the number of these is small (compared to the amount
of manual layout and config needed to assemble the UI in IB) then this
would make sense.
- (unrelated to subject) it seems that IB attempts in many situations
to try and translate "bumpycase" class names into natural text - is
this documented somewhere?
Thanks for any info,
Rick
_______________________________________________________
Richard Hoge, Ph.D.
Assistant Professor, Departments of Physiology and Radiology,
Biomedical Engineering Institute, University of Montreal
Centre de recherche de l’institut universitaire de gériatrie de Montréal
Unité de neuroimagerie fonctionnelle/Functional Neuroimaging Unit
_______________________________________________________
_______________________________________________
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