On Friday, July 5, 2002, at 12:39 PM, Sherm Pendley wrote:
> On Friday, July 5, 2002, at 02:37 PM, bob ackerman wrote:
>
>> ok. i am a not-know-much. what i know, i read in the camelbones doc.
>> please help me understand.
>
> Sorry, I didn't mean that as personal criticism. I'm just trying to get a
> handle on how others feel about having the ability to create custom
> widgets. I thought, based on your past comments, that you considered it a
> show-stopper. For my own use, I haven't found it to be very important -
> but I'm quite willing to admit that I'm the odd man out in that, if that
> turns out to be the case. :-)
>
>> are you saying we can create views in ib and use them - we just can't
>> create 'custom' views? which means what - subclassing?
>
> That's precisely the difficulty - subclassing. I haven't figured out an
> elegant way to handle the creation of a Perl subclass of an Objective-C
> superclass. Since creating a new view object - a custom gui widget, in
> other words - most often requires subclassing NSControl, that's pretty
> much ruled out until subclassing is working.
>
> On the other hand, you can use all of the standard view objects; that is,
> anything that appears on the standard IB palettes, without having to
> write any Objective-C code.
aha! my fears are allayed. i am content to use ib as is for now.
> In my own experience, I haven't found a huge need for widgets that aren't
> already provided with AppKit/IB. That, in combination with the problem of
> subclassing, has put the issue pretty low on my priority list. Like I
> said earlier, though, I'm quite willing to believe that I'm the odd man
> out, and readjust my priorities if enough people think it's important.
>
>> and i still don't think i would know how to handle them in perl.
>> perhaps just a few more little examples of how, in general, to translate
>> obj-c into perl.
>> where obj-c creates a class and calls a method with named arguments,
>> what would we do in perl?
>
> Most of the creation and connection of GUI widgets is done visually, in
> Interface Builder; your Perl controller class gets passed a reference to
> the object when the NIB is loaded. However, you can also create new ObjC
> objects from Perl.
>
> In general, Objective-C method calls of the form:
> [object method: arg1 arg2Name: arg2];
>
> Are called in Perl like this:
> $object->method_arg2Name(arg1, arg2);
>
> The argument names are concatenated with the method name, and ':' are
> turned into '_'s. If there is a trailing '_', as there would be for a
> method that took only one argument, it is removed from the Perl
> equivalent.
>
> For example, to create a mutable dictionary with an initial capacity for
> five objects, and add a single string object in Objective-C looks like
> this:
>
> NSMutableDictionary *dict;
> dict = [[NSMutableDictionary alloc] initWithCapacity: 5];
> [dict setObject: @"This is a string" forKey: @"This is the key"];
>
> The equivalent in Perl would look like this:
>
> our $dict;
> $dict = NSMutableDictionary->alloc->initWithCapacity(5);
> $dict->setObject_forKey("This is a string", "This is the key");
>
> Does that help clear it up any, or just muddy it further?
very helpful. i feel confident enough now to try and translate some of the
cocoa samples to perl.
thanks. and thanks for creating camelbones. oh. is this info somewhere
where i should have seen it, or is every camelbones user going to want to
know this stuff?
> sherm--
pob
