From: Free (rupert.barrow) <rup...@fr...> - 2005-09-13 12:43:25
|
Hi, Has anyone got Ruby/RubyCocoa and CoreData working ? Are there any examples out there, of Apps (with GUI) and/or Tools (without GUI). TIA, Rupert |
From: Jonathan P. <jp...@dc...> - 2005-09-13 14:03:45
|
On 13 Sep 2005, at 13:43, Free (rupert.barrow) wrote: > Has anyone got Ruby/RubyCocoa and CoreData working ? > Are there any examples out there, of Apps (with GUI) and/or Tools > (without GUI). Just in case you don't get any other responses to this message - I don't think anybody has tried extensively or got CoreData working yet with RubyCocoa. I haven't looked into it myself so I'm not sure what the stumbling blocks (which there are likely to be) are. Jonathan |
From: Sean L. <se...@da...> - 2005-09-13 14:55:28
|
On 13 Sep 2005, at 14:43, Free (rupert.barrow) wrote: > Has anyone got Ruby/RubyCocoa and CoreData working ? > Are there any examples out there, of Apps (with GUI) and/or Tools > (without GUI). This isn't quite the same, but bindings/KVO are used by CoreData, so this may be useful to you. I've been working on enhancing RubyCocoa's handling of Key-Value observance to allow binding driven applications. I've written a little helper that allows code like this: class Controller < OSX::NSObject attr_accessor :status, :timeConnected cocoa_property :status, :timeConnected cocoa_depends :status, [ :statusText, :isConnecting, :isConnected, :isDisconnecti ng, :isDisconnected, :isWorking ] cocoa_depends :timeConnected, [ :timeConnectedText ] end (this was from a little proof-of-concept app I wrote to handle activating a PPP connection on my server from by PB) The cocoa_property class method creates wrappers for the setter methods for those properties that trigger KVO notifications. Note this is necessary even with the CVS HEAD RubyCocoa, even with the property support in there. That support will only trigger the notifications when the property is updated from the other side of the ObjC bridge. My code ensures that Ruby code that updates the property also triggers the notifications. The cocoa_depends class method defines dependencies. This is necessary because the bridge seems to prevent the setKeys:triggerChangeNotificationsForDependentKey: class method on NSObject from operating correctly. (I haven't investigated why, but I can guess it's to do with the RubyCocoa wrapper for Ruby classes). If you're interested I can post this, alternately is there any interest in getting these into the trunk? Is there perhaps a more elegant way of achieving this? Sean -- Sean Legassick se...@da... |
From: Jonathan P. <jp...@dc...> - 2005-09-13 15:08:42
|
On 13 Sep 2005, at 15:55, Sean Legassick wrote: > If you're interested I can post this, alternately is there any > interest in getting these into the trunk? Is there perhaps a more > elegant way of achieving this? These things sound interesting. I discovered a similar problem with ruby-level changes to bridged objects not sending notifications and came up with an equivalent additional meta-method. Even if the triggerChangeNotifications... method worked, I like the idea of a ruby meta-method for setting them up - much less to type! There seem to be some differences in behaviour between Panther and Tiger. I have a vague recollection of having to disable some of my ruby-level manual change notifications after the move to Tiger, since exceptions were appearing. What OS version are you using? If you can post your code and any specifics you've identified about the way RubyCocoa interacts with the Objective C KVO system that would be great. I'll try to do the same soon with the code I have. Thanks Jonathan |
From: Sean L. <se...@da...> - 2005-09-13 16:06:40
Attachments:
_Props.rb
|
On 13 Sep 2005, at 17:08, Jonathan Paisley wrote: > Even if the triggerChangeNotifications... method worked, I like the > idea of a ruby meta-method for setting them up - much less to type! Absolutely, and I've made mine more flexible just now so you can say: cocoa_depends_on :key, :dependency cocoa_depends_on [ :key1, :key2 ], :dependency cocoa_depends_on :key, [ :dependency1. :dependency2 ] cocoa_depends_on [ :key1, :key2 ], [ :dependency1, :dependency2 ] (I think on reflection cocoa_depends_on is a little more clear than cocoa_depends) > > There seem to be some differences in behaviour between Panther and > Tiger. I have a vague recollection of having to disable some of my > ruby-level manual change notifications after the move to Tiger, > since exceptions were appearing. What OS version are you using? Tiger 10.4.2 - haven't tried this on Panther. > If you can post your code and any specifics you've identified about > the way RubyCocoa interacts with the Objective C KVO system that > would be great. I'll try to do the same soon with the code I have. I've attached my code. It relies on the property handling stuff in CVS HEAD (unless that's been released now ... ?) |
From: Jonathan P. <jp...@dc...> - 2005-09-16 11:35:55
|
>> >> There seem to be some differences in behaviour between Panther and >> Tiger. I have a vague recollection of having to disable some of my >> ruby-level manual change notifications after the move to Tiger, >> since exceptions were appearing. What OS version are you using? > > Tiger 10.4.2 - haven't tried this on Panther. Hmmn. I can't now find the code that I was thinking about after scanning the Subversion logs for my project. Hopefully it'll turn up. >> If you can post your code and any specifics you've identified >> about the way RubyCocoa interacts with the Objective C KVO system >> that would be great. I'll try to do the same soon with the code I >> have. > > I've attached my code. It relies on the property handling stuff in > CVS HEAD (unless that's been released now ... ?) Can you comment more on the problem with setKeys_triggerChangeNotificationsForDependentKey? I'm currently using it sucessfully. For example: class Foo < OSX::NSObject ["prop1","prop2","prop2"].each do |key| Foo.setKeys_triggerChangeNotificationsForDependentKey (["propX"],key) end # ... other stuff end I think I'd like to figure out the problem with the Cocoa-provided mechanisms, since then the dependency tracking should just work (since we already send change notifications through kvc_accessor). I still think cocoa_depends_on is useful since it has far nicer syntax, and can easily be reimplemented in terms of setKeys_trigger... once that works. Thanks Jonathan |
From: Sean L. <se...@da...> - 2005-09-16 12:14:29
|
On 16 Sep 2005, at 13:35, Jonathan Paisley wrote: > > Can you comment more on the problem with > setKeys_triggerChangeNotificationsForDependentKey? I'm currently > using it sucessfully. > > For example: > > class Foo < OSX::NSObject > ["prop1","prop2","prop2"].each do |key| > Foo.setKeys_triggerChangeNotificationsForDependentKey > (["propX"],key) > end > > # ... other stuff > end Yup, using it like that works for me too. Unfortunately I don't have a copy of the code where I was trying to get it to work and it didn't. I had just started tinkering around with RubyCocoa so I may have just made a silly error, or alternately it may not have been working properly on the 0.4.1 release... > I think I'd like to figure out the problem with the Cocoa-provided > mechanisms, since then the dependency tracking should just work > (since we already send change notifications through kvc_accessor). I hadn't seen kvc_reader, kvc_writer or kvc_accessor previously either - they remove the need for cocoa_property. (they weren't in the 0.4.1 release that I started out with). > I still think cocoa_depends_on is useful since it has far nicer > syntax, and can easily be reimplemented in terms of > setKeys_trigger... once that works. OK, sounds like a good idea. I no longer have any basis for asserting that setKeys_trigger... doesn't work anymore, it seems fine. Sean -- Sean Legassick se...@da... |
From: Jonathan P. <jp...@dc...> - 2005-09-16 13:42:16
|
>> I think I'd like to figure out the problem with the Cocoa-provided >> mechanisms, since then the dependency tracking should just work >> (since we already send change notifications through kvc_accessor). > > I hadn't seen kvc_reader, kvc_writer or kvc_accessor previously > either - they remove the need for cocoa_property. (they weren't in > the 0.4.1 release that I started out with). Yes, those were added after 0.4.1. I think there are quite a few limitations in 0.4.1 release that make things hard! The current CVS has got some nice features added though (like my exception-wrapping patch, which stops applications from dying unexpectedly if any uncaught ruby exceptions occur). :) >> I still think cocoa_depends_on is useful since it has far nicer >> syntax, and can easily be reimplemented in terms of >> setKeys_trigger... once that works. > > OK, sounds like a good idea. I no longer have any basis for > asserting that setKeys_trigger... doesn't work anymore, it seems fine. Would 'kvc_depends_on' be a better name, to match up with the other kvc_* methods? |
From: Sean L. <se...@da...> - 2005-09-16 13:49:07
|
On 16 Sep 2005, at 15:41, Jonathan Paisley wrote: > > Yes, those were added after 0.4.1. I think there are quite a few > limitations in 0.4.1 release that make things hard! The current CVS > has got some nice features added though (like my exception-wrapping > patch, which stops applications from dying unexpectedly if any > uncaught ruby exceptions occur). :) I'll have to take another look over CVS head for such goodies... >>> I still think cocoa_depends_on is useful since it has far nicer >>> syntax, and can easily be reimplemented in terms of >>> setKeys_trigger... once that works. >>> >> >> OK, sounds like a good idea. I no longer have any basis for >> asserting that setKeys_trigger... doesn't work anymore, it seems >> fine. >> > > Would 'kvc_depends_on' be a better name, to match up with the other > kvc_* methods? Agreed. Sean -- Sean Legassick se...@da... |
From: kimura w. <ki...@us...> - 2005-10-05 14:35:41
|
Hi, I added kvc_depends_on(keys, *dependencies) to CVS. Thanks! Tue, 13 Sep 2005 18:06:21 +0200, Sean Legassick wrote: > >On 13 Sep 2005, at 17:08, Jonathan Paisley wrote: >> Even if the triggerChangeNotifications... method worked, I like the >> idea of a ruby meta-method for setting them up - much less to type! > >Absolutely, and I've made mine more flexible just now so you can say: > >cocoa_depends_on :key, :dependency >cocoa_depends_on [ :key1, :key2 ], :dependency >cocoa_depends_on :key, [ :dependency1. :dependency2 ] >cocoa_depends_on [ :key1, :key2 ], [ :dependency1, :dependency2 ] > >(I think on reflection cocoa_depends_on is a little more clear than >cocoa_depends) -- kimura wataru |