Fujimoto Hisa
hisa****@fobj*****
Sat Feb 10 12:15:56 JST 2007
Hi,
I'm still working on the bundle/plugin support, you can see in the
bundle-support branch, and it seems almost work good at least about
SIMBL and VoodooPad plugin, though it has a problem yet (see later). I
think the api spec may be able to freeze.
I'll merge these into the apple-unstable branch soon (today or a few
days later).
the API to initialze RubyCocoa and to load a ruby program for a
bundle/plugin in Objective-C side:
BOOL RBBundleInit(
const char* path, // relative path to an initial ruby program
// for the bundle.
Class klass, // a objc-class binding with the bundle
id param); // additional parameter for you
);
An objective-c class, which is defined in a ruby program of the path
file, bind with the bundle.
And then, the ruby program which is passed by RBBundleInit is like:
require 'osx/cocoa'
OSX.init_for_bundle do
| bundle, # the bundle binding with the klass of RBBundleInit
param, # the param of RBBundleInit
logger | # simple logging utility for NSLog
logger.info("bundle=%p param=%p", bundle.to_s, param.to_s)
require 'my_class'
...
...
end
an error raised from the block is rescued by the init_for_bundle
itself and logging by NSLog, so you have not to care it.
currently two examples eixst:
sample/VPRubyPluginEnabler - VoodooPad plugin enabler
sample/RubyAnywhere - SIMBL plugin
Well, a problem exists yet. Several constants and functions can not
access from ruby program loaded by RBBundleInit. theese are e.g.:
NSApp, NSShiftKeyMask, NSRunAlertPanel, etc ...
we should fix these after the merge.
thanks
--
hisa
# btw, it may be better to merge the apple-unstable into the trunk
# already.