Re: Dynamically loading a part of a Window in Cocoa
Re: Dynamically loading a part of a Window in Cocoa
- Subject: Re: Dynamically loading a part of a Window in Cocoa
- From: Quincey Morris <email@hidden>
- Date: Wed, 1 Jul 2009 10:26:08 -0700
On Jul 1, 2009, at 08:54, Adam R. Maxwell wrote:
I'm curious as to why people recommend a tabless NSTabView for
this. I've always found tabview subviews to be a pain to set up in
IB; the alignment and sizing seem really fiddly to get right. Maybe
I've been doing something wrong.
I agree with you about the IB side of setting it up, although it
*really* depends on the particular situation.
Using multiple nibs instead of building one really complicated nib
has some distinct benefits for maintenance, in my experience.
But drawbacks, too:
-- When you add a subview, you have to write code to resize it to fit
the window real estate it's supposed to occupy. That's not hard, but
it's a line or two of glue code you don't have to write with tab views.
-- You can't hook up IBOutlets directly from the window controller to
the view controller's objects in IB. Sometimes you can eliminate the
need for the outlet or move it to the view controller. If not, it's
not terribly hard to code around, but that's a few more lines of glue
code.
-- If you modularize your controllers, then bindings from the view
controller's objects get a bit harder. Either you have to defeat the
modularization by binding to File's Owner.windowController.whatever
(File's Owner being the view controller subclass, of course, and
windowController being a property you added to it), or you have to
"proxy" the bound properties in the view controller, which means more
glue code to forward the relevant accessors *and* KVO notifications.
Regardless of that, I prefer the modular view controller approach,
along with the modular IB design approach, but I think the tab view
approach is "generally easier" in a monolithic sort of way in many
cases.
Lastly, view controllers are Leopard only, so tab views win in Tiger-
compatible apps. :)
_______________________________________________
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