On Thu, Apr 2, 2009 at 12:05 PM, ravi <ravi-lists@...> wrote:
> On Apr 2, 2009, at 12:02 AM, Sherm Pendley wrote:
> > But you're right - it may well be the first approach that a Perl
> > developer would think of. I've always thought of CamelBones as
> > providing an alternative language for Cocoa, for those occasions
> > when Perl is a better fit than Objective-C. Perhaps I've been
> > thinking too narrowly. Perhaps it could also provide an alternative,
> > more "Perlish" approach, for those occasions when a more dynamic GUI
> > is needed. It's an approach that's not very well-supported in
> > "traditional" Cocoa, in any language.
> I am curious... if you faced a situation where you had to read a user
> config file (a plist file, I guess, in Mac OS terms?), and based on
> what's in there, you had to create UI buttons, how would you do it in
> traditional Cocoa style? Or is this a very rare case?
It's a rare case. Apple's Human Interface Guidelines strongly discourage
adding and/or removing interface elements, preferring to enable and disable
them instead. So, I'd look for ways to do it that way first.
As a trivial example, I use gmail, and I'm typing this in FireFox. I haven't
used the "back" button recently, so this page is the latest item in my
browser history. The "History / Forward" menu item is still present, but
greyed out and disabled. The page has finished loading, so the "View / Stop"
menu item is still present, but greyed out and disabled.
So, what I would try to do first is find a way to apply the suggestions in
the HI guidelines. I'd ask myself, is there any way I could arrange a static
Nib so that the buttons are always present, and then enable or disable them
according to user preferences? Or, is there a way I could arrange it to use
a table or outline view, with a variable number of button cells?
If all else failed, I'd write code to create the buttons and add them to the
superview. As I said, never say "never." :-) Creating and setting up a
hierarchy of UI controls is actually more tedious than difficult. The
preference for static Nibs comes from Apple's HIG, not from any great
difficulty in building an interface dynamically.
You create NSView subclasses with -initWithFrame:, which defines their
(default) size and position. You'll probably need to set a number of other
options that are specific to the particular view type you're creating as
well, such as the target object and action selector for a button, or the
data source object for a table or outline view. Then, you add the view to
its parent view with -addSubview:.
If the parent view is resizable, you'll need to set the appropriate options
in the children with -setAutoresizingMask: - that's what is happening when
you set the "struts and springs" options in Interface Builder. That's
probably the biggest conceptual difference between Cocoa and other kits, as
far as creating a dynamic interface is concerned; rather than having a
separate "layout manager" object, in Cocoa you set the layout options for
each subview separately.
Alternatively, if you can require Leopard for your app, you might want to
consider using Core Animation and layers, which unlike "old-school" Cocoa
views, *can* use a layout manager. It's a little early to ship anything
that's Leopard-only IMHO though, so I haven't done a whole lot with CA yet.
Cocoa programming in Perl: http://camelbones.sourceforge.net