Le 3 nov. 06 à 23:55, Jonathan Paisley a écrit :
rb_main.m is in the app which loads the plugin; I have traced the Ruby code, the plugin's Ruby classes are loaded correctly.
In my earlier email, I mentioned the idea of triggering the RubyCocoa initialisation process via the dynamic linker's ability to automatically call init functions (see '-init' argument to ld).
Hopefully that may work.
This sound really complicated to me, and unnatural. I just want Cocoa to work properly and recognise my Ruby principal class.
I'm a bit confused about what's going on. Perhaps you could describe the situation you've got in more detail?
Yes, you are right, I should have been more precise.
I am developing the app *and* the plugin. The plugin is dropped into the app bundle : this can be done through the Finder's inspector, but I just added a file-copy step to my XCode project to put the plugin in the right place when the app is regenerated.
I load plugins like this. For each plugin at 'currPath' :
NSBundle *currPlugin = [NSBundle bundleWithPath:currPath]
Class currPrincipalClass = [currPlugin principalClass]; // fails for Ruby principal class
currInstance = [[currPrincipalClass alloc] init]; // create an instance of principal class
The main app is using RubyCocoa. As I said previously, for the moment (hack) the main app loads the Ruby code of all the plugins it finds, from the app's rb_main.rb, way long before the plugin is loaded.
The plugin does not use or need to use RubyCocoa (I think ?).
Maybe this is the problem : does [currPlugin principalClass] inspect OC's understanding of the plugin's Info.plist, or does it (possibly) call a plugin-initialisation method which I should override to do some magic RubyCocoa initialisation stuff ?
The plugin is built with a standard XCode "Cocoa bundle" template which includes Ruby code files in Resources.