On Apr 2, 2009, at 12:02 AM, Sherm Pendley wrote:I am curious... if you faced a situation where you had to read a user
> 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.
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.