Re: [Rubycocoa-talk] [BUG ?] [myPlugin principalClass]=nil if plugin's main class is Ruby

[Rupert B. <rup...@fr...>]

I have modified rb_main.rb to load all Ruby files found in plugins in =20=

the app's bundle, at the same time as other Ruby files (in the app's =20
Resources) are loaded.
So, the Ruby class exists when the OC plugin-loading code is called.
The problem seems to be that Cocoa's OC plugin-loading methods must =20
check that the principal class mentioned in the plugin's Info.plist =20
*does* exist (or *is* registered) somewhere in the OC world. It does =20
not seem to find the Ruby class I have declared as principal class.

Rup

PS : obviously, if I switch the Ruby principal to an equivalent OC =20
class, the whole thing works properly.


Le 2 nov. 06 =C3=A0 17:31, Jonathan Paisley a =C3=A9crit :

> On 23 Oct 2006, at 0:01, Rupert BARROW wrote:
>
>> I've just posted the following bug report on SourceForge : what do
>> you think about it ?
>>
>>
>> In Objective C :
>> 	NSBundle *currPlugin =3D [NSBundle bundleWithPath:currPath];
>> 	Class currPrincipalClass =3D [currPlugin principalClass];
>>
>> When I have defined a plugin with a main class which is a Ruby class,
>> this last call returns nil, even if the bundle's Info.plist is
>> correct, with principalClass well defined.
>
> I don't think this is going to work. RubyCocoa dynamically creates =20
> Objective C classes as you define them in code by subclassing =20
> OSX::NSObject.
>
> Therefore, the class you've named in the Info.plist doesn't exist =20
> until the necessary ruby code is executed.
>
> What steps have you taken to build your plugin?
>
> You might get things to work by using the '-init symbolname' =20
> argument to the linker in order to get a C function to be called =20
> when the dynamic library is loaded. That C function would, in turn, =20=

> initialise RubyCocoa and load in your *.rb files. They would =20
> created the necessary Objective C classes.
>
>
>
>
>
>