rubycocoa-talk — talking about RubyCocoa

Re: [Rubycocoa-talk] methodSignature is nil.

[Dave H. <gr...@gr...>]

On Jun 17, 2005, at 1:49 AM, Jonathan Paisley wrote:

> Have you told the table that you've updated the data source? Call 
> reloadData on the table view.

No. That's the part that I meant when I said "I think I know how to 
make this work." I have to create an 'ib_outlet :myTable ' entry in 
Ruby and do the corresponding mojo in Interface Builder so that I can 
then call a reload on the view.

> To be honest, I think for this application you're better to use the 
> standard datasource techniques rather than bindings. Bindings tend to 
> be more useful when there's different ways to edit or view data (e.g., 
> both directly in the table and also in a bunch of fields below the 
> table).

Hmm. OK.

> The current release of RubyCocoa (0.4.1) doesn't support bindings 'out 
> of the box'. There's some extra code you need to get it to work.

Aha! I feel less dumb. :)

>  This has since been integrated into CVS, so the next release will 
> have it.

I'll wait.

So, um, is RubyCocoa 'out of the box' working with Core Data from Tiger 
and XCode 2.0? Fiddling with bindings here just seemed like a good 
opportunity to experiment, but my next project has "I (heart) Core 
Data" written all over it.

Re: [Rubycocoa-talk] methodSignature is nil.

[Cornelius J. <cj...@vi...>]

hi

also if you use bindings updating your array directly won't notify kvo.
you have to use the proper cover methods required.

if you have am images array you should implement the following and  
update your array using these, sorry, not translated to ruby

- (unsigned int)countOfImages {
     return [images count];
}

- (id)objectInImagesAtIndex:(unsigned int)index {
     return [images objectAtIndex:index];
}

- (void)insertObject:(id)anObject inImagesAtIndex:(unsigned int)index
{
     [images insertObject:anObject atIndex:index];
}

- (void)removeObjectFromImagesAtIndex:(unsigned int)index
{
     [images removeObjectAtIndex:index];
}

- (void)replaceObjectInImagesAtIndex:(unsigned int)index withObject: 
(id)anObject
{
     [images replaceObjectAtIndex:index withObject:anObject];
}

- (NSMutableArray *) images
{
     return images;
}

- (void) setImages: (NSArray *)newImages
{
     if (images != newImages)
     {
         [images autorelease];
         images = [[NSMutableArray alloc] initWithArray: newImages];
     }
}

I imagine the cover methods are necessary to avoid having older code  
exhibiting strange side effects (ie sending notifications around it  
didn't used to send)
and to abstract (read differentiate) the bindings layer

hth

cornelius

On Jun 17, 2005, at 10:49 AM, Jonathan Paisley wrote:

> The current release of RubyCocoa (0.4.1) doesn't support bindings  
> 'out of the box'. There's some extra code you need to get it to  
> work. This has since been integrated into CVS, so the next release  
> will have it. You can see what's required by looking at the FAQ:  
> http://rubycocoa.sourceforge.net/w.en/FAQ.html "I'm trying to use  
> Cocoa Bindings but all I get is an error message saying that my  
> class is not key value coding-compliant (kvc)". There's a DMG of a  
> sample project linked at the end of the FAQ entry.

Cornelius Jaeger,
Member of Visual FOOD GmbH - Software and Multimedia Solutions

http://www.screenfood.ch
http://www.visualfood.ch
Moosstrasse 7
CH-6003 Lucerne
SWITZERLAND

Fon: +41 (0)41 21 0 21 41
Fax: +41 (0)41 21 0 21 43

iChat or AIM ne...@ma...

Re: [Rubycocoa-talk] methodSignature is nil.

[Jonathan P. <jp...@dc...>]

On 16 Jun 2005, at 17:44, Dave Howell wrote:
> On Jun 14, 2005, at 12:01 AM, Jonathan Paisley wrote:
>
>> For this to work, you'd need to do  
>> NSImage.alloc.initByReferencingFile(blahblah).
>>
>> However, I there's also NSImage.imageNamed(blahblah) which should  
>> work.
>>
>
> Ah. Just when I thought I'd finally managed to really internalize  
> and keep separate classes and instantiations, Obj-C rises up and  
> bites me with the same thing. Hmm.
>     OK, so the NSImage.alloc.initByReferencingFile(blahblah) didn't  
> seem to work either, but NSImage.imageNamed(blahblah) worked  
> perfectly. :) :)
>
> Except that it doesn't automatically update. If I roll the dice,  
> and replace the data in the array, it only updates when I move  
> focus to another app or back. I'm pretty sure I know how to fix  
> that, but I thought to myself "oho! Wouldn't this be better if I  
> used Bindings instead of simulating a datasource?"

Have you told the table that you've updated the data source? Call  
reloadData on the table view.

To be honest, I think for this application you're better to use the  
standard datasource techniques rather than bindings. Bindings tend to  
be more useful when there's different ways to edit or view data  
(e.g., both directly in the table and also in a bunch of fields below  
the table).

> Well, maybe, but now I can't get *that* to work. All the examples I  
> find are too complicated; they assume that I want to the user to be  
> able to edit and fiddle. This is display only, so I need to be able  
> to write into the array programmatically and have it update. I  
> think what's not working is that I can't convince the table view to  
> actually connect to the array.

This reinforces my point above - they're all too complicated because  
it's most useful when you have that complexity.

I suggest you go back to using a table datasource and try calling  
reloadData on the table view.

> I'm mostly working off the Intro To Cocoa Bindings article on the  
> cocoadevcentral site, which creates a little email mailbox &  
> messages app. The final "code" for the project is this:
>
> @interface MyController : NSObject
> {
>     NSMutableArray * _mailboxes;
> }
>
> - (NSMutableArray *) mailboxes;
> - (void) setMailboxes: (NSArray *)newMailboxes;
>
> @end
>
>
> I can't quite figure out how that translates into RubyCocoa. (The  
> initial {} part is mystifying, dumb old Obj-C grumble grumble.)  
> Here's my best guess so far:

Not dumb: the {} bit is just the declaration of instance variables.

>
> class  MyController < OSX::NSObject
>     include OSX
>
>     ib_outlet :mailboxes
>
>     def initialize
>         @mailboxes = NSMutableArray.alloc.init
>     end
> end
>
> There's no 'def setMailboxes' because I don't want mine to be  
> writable, so I haven't been trying to figure out the correct syntax  
> for that. Anything wrong so far?

Bear in mind that preventing the array from being replaced is not the  
same as preventing its contents from being changed. The contents  
could be changed both by calling methods on the array  
(@mailboxes.addObject) and also by changing the properties of any of  
the contained objects.

> I scrapped and rebuilt all the stuff in Interface Builder, and now  
> something appears to be connected that wasn't connected before.  
> Instead of just launching silently, now when I launch it aborts  
> with this error:

> this class is not key value coding-compliant for the key diceRoll

The current release of RubyCocoa (0.4.1) doesn't support bindings  
'out of the box'. There's some extra code you need to get it to work.  
This has since been integrated into CVS, so the next release will  
have it. You can see what's required by looking at the FAQ: http:// 
rubycocoa.sourceforge.net/w.en/FAQ.html "I'm trying to use Cocoa  
Bindings but all I get is an error message saying that my class is  
not key value coding-compliant (kvc)". There's a DMG of a sample  
project linked at the end of the FAQ entry.

Re: [Rubycocoa-talk] methodSignature is nil.

[Dave H. <gr...@gr...>]

On Jun 16, 2005, at 9:44 AM, Dave Howell wrote:
>  I think what's not working is that I can't convince the table view to 
> actually connect to the array.

I've made some progress, I think.

I scrapped and rebuilt all the stuff in Interface Builder, and now 
something appears to be connected that wasn't connected before. Instead 
of just launching silently, now when I launch it aborts with this 
error:

this class is not key value coding-compliant for the key diceRoll

diceRoll is equivalent to "mailboxes" in the previous example; that is, 
it's an NSMutableArray defined and initialized in my Controller class. 
I've tried both

	ib_outlet :diceRoll

and/or

	def diceRoll
		blah blah
	end

Still can't get the app to find the key at runtime....

Re: [Rubycocoa-talk] methodSignature is nil.

[Dave H. <gr...@gr...>]

On Jun 14, 2005, at 12:01 AM, Jonathan Paisley wrote:

> For this to work, you'd need to do 
> NSImage.alloc.initByReferencingFile(blahblah).
>
> However, I there's also NSImage.imageNamed(blahblah) which should work.

Ah. Just when I thought I'd finally managed to really internalize and 
keep separate classes and instantiations, Obj-C rises up and bites me 
with the same thing. Hmm.
	OK, so the NSImage.alloc.initByReferencingFile(blahblah) didn't seem 
to work either, but NSImage.imageNamed(blahblah) worked perfectly. :) 
:)

Except that it doesn't automatically update. If I roll the dice, and 
replace the data in the array, it only updates when I move focus to 
another app or back. I'm pretty sure I know how to fix that, but I 
thought to myself "oho! Wouldn't this be better if I used Bindings 
instead of simulating a datasource?"

Well, maybe, but now I can't get *that* to work. All the examples I 
find are too complicated; they assume that I want to the user to be 
able to edit and fiddle. This is display only, so I need to be able to 
write into the array programmatically and have it update. I think 
what's not working is that I can't convince the table view to actually 
connect to the array.

I'm mostly working off the Intro To Cocoa Bindings article on the 
cocoadevcentral site, which creates a little email mailbox & messages 
app. The final "code" for the project is this:

@interface MyController : NSObject
{
     NSMutableArray * _mailboxes;
}

- (NSMutableArray *) mailboxes;
- (void) setMailboxes: (NSArray *)newMailboxes;

@end


I can't quite figure out how that translates into RubyCocoa. (The 
initial {} part is mystifying, dumb old Obj-C grumble grumble.) Here's 
my best guess so far:

class  MyController < OSX::NSObject
	include OSX

	ib_outlet :mailboxes

	def initialize
		@mailboxes = NSMutableArray.alloc.init
	end
end


There's no 'def setMailboxes' because I don't want mine to be writable, 
so I haven't been trying to figure out the correct syntax for that. 
Anything wrong so far?

Re: [Rubycocoa-talk] methodSignature is nil.

[Jonathan P. <jp...@dc...>]

On 13 Jun 2005, at 23:50, Dave Howell wrote:

> Sigh. I'm back. I'm staring at a misleading error message, and am  
> mystified.
>
> /Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/ 
> osx/objc/oc_wrapper.rb:17:in `ocm_send':  
> NSImage#initByReferencingFile: - methodSignature is nil.  
> (OSX::OCMessageSendException)
>
> I *think* "methodSignature is nil" is somebody's (Cocoa?  
> RubyCocoa?) way of saying "no method by that name found here."

Yes.

> Um? NSImage definitely has such a method. So something else is  
> wrong. But I have no idea what it is. It can't find NSImage? I'm  
> not asking for its method in the right way? I sent the wrong  
> parameters, or the wrong type of parameters, or the wrong class of  
> parameters, or the wrong number of parameters?

NSImage *instances* have such a method, but the NSImage *class* does  
not. You can tell the difference in the Cocoa documentation because  
class methods have a + at the beginning, and instance methods have a  
- [*].

> @myImages = Array.new(6) {|i|     NSImage.initByReferencingFile 
> ("Image" + (i+1).to_s + ".gif")}
>
> My XCode project has files named "Image1.gif" "Image2.gif" . . .  
> "Image6.gif" in it. The AppleScript version finds them as planned.

For this to work, you'd need to do NSImage.alloc.initByReferencingFile 
(blahblah).

However, I there's also NSImage.imageNamed(blahblah) which should work.


[*] For example:
+ (id)imageNamed:(NSString *)name

- (id)initByReferencingFile:(NSString *)filename

[Rubycocoa-talk] methodSignature is nil.

[Dave H. <gr...@gr...>]

Sigh. I'm back. I'm staring at a misleading error message, and am  
mystified.

/Library/Frameworks/RubyCocoa.framework/Versions/A/Resources/ruby/osx/ 
objc/oc_wrapper.rb:17:in `ocm_send': NSImage#initByReferencingFile: -  
methodSignature is nil. (OSX::OCMessageSendException)

I *think* "methodSignature is nil" is somebody's (Cocoa? RubyCocoa?)  
way of saying "no method by that name found here."

Um? NSImage definitely has such a method. So something else is wrong.  
But I have no idea what it is. It can't find NSImage? I'm not asking  
for its method in the right way? I sent the wrong parameters, or the  
wrong type of parameters, or the wrong class of parameters, or the  
wrong number of parameters?

@myImages = Array.new(6) {|i| 	NSImage.initByReferencingFile("Image" +  
(i+1).to_s + ".gif")}

My XCode project has files named "Image1.gif" "Image2.gif" . . .  
"Image6.gif" in it. The AppleScript version finds them as planned.

Hints and clues gratefully awaited.

Re: [Rubycocoa-talk] kcode_to_nsencoding

[kimura w. <ki...@us...>]

Hi,

Sun, 12 Jun 2005 21:25:05 +0100, Jonathan Paisley wrote:
>Hi,
>
>I was looking at the code below in CVS. Is it safe to compare kcode  
>to constant strings like that? Is it guaranteed that the linker will  
>make them unique?
>
No, that is a bad code. I should use strcmp(3) and checked in to CVS.
Thanks.


-- 
kimura wataru

[Rubycocoa-talk] [PATCH] Catching and bridging Ruby exceptions

[Jonathan P. <jp...@dc...>]

Hi,

The patch attached to this message (against CVS today) adds support  
for catching Ruby exceptions from code called by Objective C code.

This is important since any Ruby-implemented actions (as hooked up in  
Interface Builder) currently cause the application to terminate if  
they raise an exception. Normal Objective C exceptions cause the  
exception to be logged but the application resumes the event handling  
loop.

With this patch, Ruby and Objective C exceptions are bridged  
transparently.

Test cases are included in the patch.

[Rubycocoa-talk] kcode_to_nsencoding

[Jonathan P. <jp...@dc...>]

Hi,

I was looking at the code below in CVS. Is it safe to compare kcode  
to constant strings like that? Is it guaranteed that the linker will  
make them unique?

Thanks
Jonathan


--- framework/src/objc/ocdata_conv.m    9 Aug 2003 14:23:24 -0000    1.7
+++ framework/src/objc/ocdata_conv.m    19 Apr 2005 15:31:57 -0000     
1.10
@@ -727,3 +732,32 @@
    return f_success;
}
+
+static NSStringEncoding kcode_to_nsencoding(const char* kcode)
+{
+  if (kcode == "UTF8")
+    return NSUTF8StringEncoding;
+  else if (kcode == "SJIS")
+    return CFStringConvertEncodingToNSStringEncoding 
(kCFStringEncodingMacJapanese);
+  else if (kcode == "EUC")
+    return NSJapaneseEUCStringEncoding;
+  else // "NONE"
+    return NSUTF8StringEncoding;
+}
+#define KCODE_NSSTRENCODING kcode_to_nsencoding(rb_get_kcode())

Re: [Rubycocoa-talk] Bindings working with notification from Ruby

[kimura w. <ki...@us...>]

Hi,

This patch was merged to CVS HEAD.
Thanks!

Thu, 28 Apr 2005 08:57:07 +0100, Jonathan Paisley wrote:
>I've attached a patch to this message that extends the base Ruby-Cocoa  
>bridge class methods. addRubyMethod_withType allows creation of an  
>actual ObjC method corresponding to a ruby method. This means that  
>key-value coding will be able to find the actual method when it does a  
>lookup.
>
>This could be used to define real accessor methods (therefore avoiding  
>the valueForUndefinedKey hook), or for implementing array accessors  
>(which have no such hook). For example:
>
>     def kvc_array_accessor(*args)
>       kvc_accessor(*args)
>       args.each do |v|
>         n = v.to_s
>         n[0..0] = n[0..0].upcase
>         self.addRubyMethod_withType("countOf#{n}".to_sym,"i4@8:12")
>          



-- 
kimura wataru

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Dave H. <gr...@gr...>]

On Jun 6, 2005, at 8:22 AM, Kevin Bullock wrote:

> If Objective-C syntax seems obtuse, it's only because it bridges the 
> world of good, dynamic, object-oriented programming languages with C,

>  Objective-C is much nicer than programming in pure C, though,

Yup. I knew this. Shortly after graduation from college (with a degree 
in Music Composition, btw), I  got a C compiler in order to learn C. My 
languages at that point included BASIC, Pascal, REXX, and Modula-2. I 
was absolutely appalled by C, and ran screaming after a month or two.

[recommended resources for C and Obj-C]

> After you've got a decent grasp on that, starting from the beginning 
> of MacDevCenter's Cocoa Programming series is a very good way to get 
> introduced to the things Cocoa can do and the architecture for doing 
> so.

The problem is, realistically, as a "programming non-programmer," I 
don't have enough time to learn it from the ground up. More on this 
below....

> More generally, though, don't get discouraged if you don't immediately 
> "get" Cocoa. While it's very well-architected, it's still a large, 
> powerful, and therefore complex software system. I've been poking at 
> it since 10.1.x and I still haven't learned all its capabilities, 
> especially since they add more with each minor revision.

Not discouraged. Cocoa is clearly a freakin' Pandora's Box of instant 
gratification wrapped in a fog of inadequate documentation. When I say 
"inadequate," I can refer only to what's actually sitting in front of 
me. What I clearly need is the right kind of Cocoa book. Well, I need 
the same kind of Ruby book too, but I already know it doesn't exist.

Any/every language or system needs a good reference. For Cocoa and 
AppleScript Studio, Apple's documentation is really superb. Alas, the 
RDoc/gem/whatnot online system for Ruby has proven quite exasperating, 
but the Practical Programmer's guide's latter half is a very good 
reference for Ruby.

For a language, the next thing would be a tutorial. Alas, the PPRuby 
book is a very poor tutorial. I think this is mostly because Ruby's 
very weird (as in, very non-procedural), and the tutorial section is 
waaay too short to have a chance of really getting there. The fact they 
think I'm a convert from Java doesn't help any either. :) Getting into 
Ruby itself has been a real slog because of the lack of a good 
tutorial, but I'm finally getting to the point of having some paradigm 
models in my head so I can go "if I wanted to do X, where would I look 
for that ability?" and thus find the answer in the reference section.

What I now need for Cocoa (and Ruby, and RubyCocoa) is a cookbook. 
"Here are fifty different kinds of 
programs/processes/functions/activities you might want to do/have/make. 
Here's a quick example of that, and a mention of one or two alternative 
approaches." So if I'm making a To Do list manager, I find the "address 
book" or "mail merger" or "recipe book" and go "ahh, there's an example 
of organizing Ruby objects as a tree," or "oh, an NSOutlineWhatever, 
that sounds perfect."

The reference works document sharedApplication or Array.push, but a 
cookbook tells me what it's there *for*.

A cookbook is more than just examples. It's (hopefully) *good* 
examples, and well chosen. "We're doing it this way because...." "You 
could choose one of these, based on..." The /Developer/Examples folder 
isn't a cookbook because most of what's in there just illustrates how 
to use individual parts. "Here's talking to Bluetooth." "Here's a table 
with a datasource."

Thank you all for for your collective polite and informative responses 
to my pathetic whining posts. I have a much better idea of what I need 
in order to keep moving forward, as well as a much better understanding 
of what RubyCocoa needs (and doesn't need). RubyCocoa needs a lot less 
documentation that I thought a week ago. All it's really missing is a 
good tutorial written for somebody coming from Ruby toward Cocoa. Most 
of the current documentation (all the examples that come with 
RubyCocoa, for instance) assume a pre-existing Cocoa background.

I may have to write that, in my copious free time. <grin>

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Jonathan P. <jp...@dc...>]

>
>
> the rb_main.rb file contains
>
>     if $0 == __FILE__ then
>       rb_main_init
>       OSX.NSApplicationMain(0, nil)
>     end
>
> if it instead had
>
>     if $0 == __FILE__ then
>       rb_main_init
>       app = OSX.NSApplicationMain(0, nil)
>     end
>
> would that work? I tried that, but it appears that "app" was too  
> local, and vanished before I could access it. But it's quite  
> possible I just don't have a good enough grasp of variable scope to  
> have figured out how to set that up correctly.

That won't work. NSApplicationMain doesn't return until the  
application exits - it handles running the main event loop of the  
application.

If you look at the documentation for the NSApplicationMain function,  
you'll see that it returns an int (not an NSApplication*):

    NSApplicationMain
    Called by the main function to create and run the application.

    int NSApplicationMain(int argc, const char *argv[])
> "sharedApplication only performs the initialization once; if you  
> invoke it more than once, it simply returns the NSApplication  
> object it created previously."

This is a common idiom in Cocoa. There are lots of class-level  
sharedBlah methods that return a singleton.

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Dave H. <gr...@gr...>]

On Jun 6, 2005, at 12:47 AM, Jonathan Paisley wrote:

> Look at the documentation for [NSApplication sharedApplication] - this 
> is the method you use to get a reference to the single NSApplication 
> object. This happens to be stored in the global variable NSApp too for 
> convenience, but I don't think it's accessible from Ruby.
>
> So, you'd do:
>
>   app = OSX::NSApplication.sharedApplication

the rb_main.rb file contains

	if $0 == __FILE__ then
	  rb_main_init
	  OSX.NSApplicationMain(0, nil)
	end

if it instead had

	if $0 == __FILE__ then
	  rb_main_init
	  app = OSX.NSApplicationMain(0, nil)
	end

would that work? I tried that, but it appears that "app" was too local, 
and vanished before I could access it. But it's quite possible I just 
don't have a good enough grasp of variable scope to have figured out 
how to set that up correctly.

> Having said this, I think it's rare that you actually need a reference 
> to the application itself - what do you need it for?

I'm trying to get my hands on the window list, in this particular case, 
although I've certainly used the "hidden," "name," and "active" 
properties in the past. I spent a lot of time scouring the Apple 
documentation trying to find a way to get an app's list of windows, 
rereading the documentation for NSWindow, NSApplication, and 
NSWindowController as well as the "how to use windows" section, and 
found no hint of any alternative to the application's "windows" method.

OTOH, I guess I need to serve myself up a slice of humble pie, since I 
did say "I don't think a Cocoa manual's going to be much help there," 
but it turns out that a single sentence in the NSApplication 
documentation did actually have the answer...

"sharedApplication only performs the initialization once; if you invoke 
it more than once, it simply returns the NSApplication object it 
created previously."

Hmmm.

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Kevin B. <krb...@ma...>]

If Objective-C syntax seems obtuse, it's only because it bridges the  
world of good, dynamic, object-oriented programming languages with C,  
which is *the* systems and application programming language (even if C 
++ seems to have taken C's place, a lot of C++ code is still  
basically C: look at the Windows API, or Carbon). Objective-C is much  
nicer than programming in pure C, though, because you don't have to  
deal with things like strings, arrays, and memory management at a low  
level. Nor structs nor typedefs nor other such weirdness.

I'm not assuming anything about your programming background, but if  
you'd like, here's my recommended reading list for getting into  
Objective-C and Cocoa. Some of it's dense, but should nonetheless be  
useful if you chew on it for a while.

Just enough C to understand Objective-C better:
http://www.macdevcenter.com/pub/a/mac/2003/07/22/cocoa_series.html
http://www.macdevcenter.com/pub/a/mac/2003/08/01/cocoa_series.html
http://www.macdevcenter.com/pub/a/mac/2003/08/19/cocoa_series.html
http://www.macdevcenter.com/pub/a/mac/2003/09/09/cocoa_series.html
http://www.macdevcenter.com/pub/a/mac/2003/10/07/cocoa.html
http://www.macdevcenter.com/pub/a/mac/2004/01/13/cocoa.html

Apple's intro to Objective-C:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ 
index.html

After you've got a decent grasp on that, starting from the beginning  
of MacDevCenter's Cocoa Programming series is a very good way to get  
introduced to the things Cocoa can do and the architecture for doing so.

More generally, though, don't get discouraged if you don't  
immediately "get" Cocoa. While it's very well-architected, it's still  
a large, powerful, and therefore complex software system. I've been  
poking at it since 10.1.x and I still haven't learned all its  
capabilities, especially since they add more with each minor revision.

Hope this helps.

Pacem in terris / Mir / Shanti / Salaam / Heiwa
Kevin R. Bullock

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Cornelius J. <cj...@vi...>]

setting the default app delegate comes to mind.
you can register for all the notifications manually of course, but  
that will take some typing.

>
> Having said this, I think it's rare that you actually need a  
> reference to the application itself - what do you need it for?

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Jonathan P. <jp...@dc...>]

On 5 Jun 2005, at 23:31, Dave Howell wrote:

> Of course. I don't expect to have Cocoa documented in Ruby per se.  
> What I'm missing are critical details about the interface.
>
> For example, where on earth is the application itself? The Obj-C- 
> based documentation states that the variable "NSApp" contains the  
> application object. When I use AppleScript, the application is the  
> default environment until/unless I use a
>     tell app "Somebody Else"
>         blah blah blah
>     end tell
> block to change my context.
>
> I haven't found any hints so far for getting my hands on the  
> application itself in Ruby. I don't think a Cocoa manual's going to  
> be much help there.
>

RubyCocoa is a lot closer to the Objective C interface than the  
AppleScript one.

Look at the documentation for [NSApplication sharedApplication] -  
this is the method you use to get a reference to the single  
NSApplication object. This happens to be stored in the global  
variable NSApp too for convenience, but I don't think it's accessible  
from Ruby.

So, you'd do:

   app = OSX::NSApplication.sharedApplication

Having said this, I think it's rare that you actually need a  
reference to the application itself - what do you need it for?

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Cornelius J. <cj...@vi...>]

hi

according to kimura check out the cvs version and you should be fine.
i'll be delving into this the next few months.
i'd like to reiterate what's been said here though.
go look at some of the obj-c or java tutorials to wrap your head  
around at least the target-action paradigm.
Bindings and CoreData are very nice and i've used them extensively,  
including CoreData's predecessor or older sibling, enterprise objects  
framework.
They make developing very simple if you understand what is happening  
underneath it all, to a certain degree, but if things go wrong you  
need to know why.
No one can save you this time, you have to learn it.
I also recommend getting some doc tool like appkido that saves you a  
lot of time on finding documentation.
enjoy it.

- cornelius

NSApp, btw, is simply a global variable that points to [NSApplication  
sharedApplication]


On Jun 6, 2005, at 1:09 AM, Dave Howell wrote:

>
>
>> An example for Cocoa Bindings
>>
>
> Good grief. It looks like the mystic powers of bindings will make  
> 2/3rds of my current code obsolete. And the Core Data system in  
> XCode 2.0 should make Bindings *and* my remaining Ruby code obsolete.
>
> Looks like I need Tiger, and square 1.
>
> Does RubyCocoa work with XCode 2.0 and/or Tiger?
>

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Dave H. <gr...@gr...>]

On Jun 4, 2005, at 4:23 PM, Jonathan Paisley wrote:

> An example for Cocoa Bindings

Good grief. It looks like the mystic powers of bindings will make 
2/3rds of my current code obsolete. And the Core Data system in XCode 
2.0 should make Bindings *and* my remaining Ruby code obsolete.

Looks like I need Tiger, and square 1.

Does RubyCocoa work with XCode 2.0 and/or Tiger?

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Dave H. <gr...@gr...>]

On Jun 5, 2005, at 2:38 PM, Sam Roberts wrote:

> I don't think you can use ruby cocoa without having a basic
> understanding of cocoa coding

That makes sense.

> with obj-c.

Happily, I don't think this is the case, which is good, because the 
more I have to fiddle with Objective-C, the more I detest it.  Its 
basic syntax is catastrophically obtuse. I find AppleScript (for 
example) far more clear and readable. Alas, the AppleScript <-> Cocoa 
bridge is woefully incomplete. One of the things that drove me to Ruby 
(and RubyCocoa) in the first place. (And one reason I won't go near 
Perl with a ten-foot pole.)

> The ruby-cocoa developers can't document cocoa, its too huge, and there
> are lots of great cocoa books around.

Of course. I don't expect to have Cocoa documented in Ruby per se. What 
I'm missing are critical details about the interface.

For example, where on earth is the application itself? The Obj-C-based 
documentation states that the variable "NSApp" contains the application 
object. When I use AppleScript, the application is the default 
environment until/unless I use a
	tell app "Somebody Else"
		blah blah blah
	end tell
block to change my context.

I haven't found any hints so far for getting my hands on the 
application itself in Ruby. I don't think a Cocoa manual's going to be 
much help there.

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Sam R. <sro...@un...>]

Quoting gr...@gr..., on Sun, Jun 05, 2005 at 02:26:20PM -0700:
> There are a lot of strange little details that I have to weedwack when 
> connecting things up. The RubyCocoa documentation is extremely terse, 
> so I have to
> 	figure out what Cocoa is capable of
> 	figure out which pieces of Cocoa do that
> 	figure out how they connect
> 	figure out which parts I need to be able to 'touch'
> 	figure out how to connect those parts to Ruby

I don't think you can use ruby cocoa without having a basic
understanding of cocoa coding with obj-c. Once you have that
understanding, I think you could play around in ruby and figure lots of
stuff out really quickly, more quickly than coding in obj-c, but
not until you have the basics.

My attempts to use ruby-cocoa stalled hard before I got as far as you.
Learning basic cocoa in obj-c is now on my todo list, and saving all the
messages on this mailling list for future reference!

The ruby-cocoa developers can't document cocoa, its too huge, and there
are lots of great cocoa books around. And the situation is no different
than the Ruby TK or Ruby-Gnome bindings, for example, check out:

  www.rubycentral.com/book/ext_tk.html
  ruby-gnome.sourceforge.net

They all say the same thing, "we document the ruby bindings, but go to
the sources to learn more about tk/gtk coding".

Cheers,
Sam

Re: [Rubycocoa-talk] Objective-C Ubiquity?

[Dave H. <gr...@gr...>]

On Jun 4, 2005, at 4:23 PM, Jonathan Paisley wrote:

> With bindings you often don't need an outlet for the text field at 
> all. You just have an NSString in your object bound to the text field 
> - Cocoa Bindings takes care of keeping the text field in sync with the 
> string.

OK, I understand this in theory, but I'm mystified by how it'd work in 
practice.

Where would I instantiate this particular NSString, what would it look 
like in Ruby, and how does it get bound to the text field?

> An example for Cocoa Bindings (found using Google):

Aha. Perfect example. I didn't even know that I wanted to know about 
'bindings.'  I note that this article says "you need to be comfortable 
with Xcode, Interface Builder, and have a solid understanding of 
Objective-C syntax in general." Oh, boy. Well, no time like the 
present. :)


There are a lot of strange little details that I have to weedwack when 
connecting things up. The RubyCocoa documentation is extremely terse, 
so I have to
	figure out what Cocoa is capable of
	figure out which pieces of Cocoa do that
	figure out how they connect
	figure out which parts I need to be able to 'touch'
	figure out how to connect those parts to Ruby

On the one hand, there are an amazing number of things that Cocoa sorta 
just 'makes happen.' That can be very cool, but it can also make it 
mystifying when I need to break into something that's normally 
automatic. Although frequently, the fact I think I need to means I 
haven't found the right place to plug into the excitement. <scratch 
head>


For example, when using AppleScript Studio, for any one nib file (like, 
say, MainMenu.nib), I get a list of every separate AppleScript file in 
the project, and can connect different UI elements to different 
scripts. [Since I remain absolutely mystified as to how different 
script files can share variables, this is more or less useless to me, 
but I can do it.] I can't figure out how to do the equivalent 
activities in Ruby. The association of IB insubstantiations of custom 
classes appears to be quite automatic, and I haven't figured out the 
relationship between .nib files and .rb files yet. 

Re: [Rubycocoa-talk] tiger and nsobjectcontroller

[Cornelius J. <cj...@vi...>]

hi kimura,
>
> Thanks for your repoting. I confirmed the message.

my pleasure, is this the place to report or do you have a bug  
reporter you prefer?


> I commited to CVS for supporting Cocoa Bindings and a sample
> "CurrencyConverter". The next release of RubyCocoa will supports the
> feature. I think Core Data works with RubyCocoa, but not tested.

great i will check out on monday or tonight, want to watch  
incredibles with my daughter now!

thx

cornelius

Re: [Rubycocoa-talk] tiger and nsobjectcontroller

[kimura w. <ki...@us...>]

Hi,

Sat, 4 Jun 2005 23:14:35 +0200, Cornelius Jaeger wrote:
>hi all
>
>two questions,
>all xcode related examples seem to have bugs, or the same bug:
>nsview not initialized correctly, did you forget to call super?
>
>i guess this is within the framework, cause the code seems fine on  
>first glance.
>
Thanks for your repoting. I confirmed the message.

>second question, does RubyCocoa support bindings and core data?
>if not, what work remains, and how can i help?
>i'm new to ruby, but i've been to objective-c land since nextstep and  
>java for 5 years, plus i've been around python on and off for what's  
>worth.
>
I commited to CVS for supporting Cocoa Bindings and a sample 
"CurrencyConverter". The next release of RubyCocoa will supports the
feature. I think Core Data works with RubyCocoa, but not tested.



-- 
kimura wataru

Re: [Rubycocoa-talk] Shared Knowledge

[Jonathan P. <jp...@dc...>]

On 5 Jun 2005, at 0:12, Dave Howell wrote:

> So where's a good place to put things I've learned that others  
> might want to know? I managed to break my window loaders three  
> times while trying to get things organized before finally figuring  
> out what was going on.

I'd suggest this mailing list, and perhaps also the Wiki:

    http://rubycocoa.sourceforge.net/w.en/