[R-SIG-Mac] Plugin interface (Was: Trying again: package for Growl Notifications)

[Byron Ellis]

On Dec 8, 2004, at 5:40 PM, Simon Urbanek wrote:

> Hi Byron,
>
> On Dec 8, 2004, at 7:54 PM, Byron Ellis wrote:
>
>> For some reason this never went out to the list last night, so I'll 
>> give it another shot (apologies if the original mysteriously 
>> appears):
>>
>> I got tired of patching the GUI source tree so I wrapped up my Growl 
>> Notifications as a package. As an added bonus it also now works from 
>> command-line R as well (ESS, X11, etc) though it can't detect when 
>> the command-line R is active and suppress notifications. I also added 
>> a 'growlnotify' function that lets you send an arbitrary notification 
>> message from R.
>
> just in case I forgot to respond to your first "growl" mail:
> I'd veto general inclusion of the "growl" patch, because it's a 
> non-standard addition to the system, which the majority of users don't 
> have. However, it highlights the need for some plug-in concept in our 
> GUI - the question is what functionality should we expose to such 
> plugins? Cocoa has nice ways of building plugin concepts, but we'd 
> need to define the GUI<->Plugin interface first. Any ideas?

Sure, no problem---it was just something I had done to my own version 
of R since the long running code I'm using throws the GUI into a very 
unresponsive state (on purpose) and I wanted to me reminded when it 
completed. Of course, the nice part about the Growl patch is that the 
weak linking means that the R GUI can detect the presence or absence of 
Growl and disable the functionality if the latter case. Either way, it 
hardly matters now that I've wrapped it up as a package. :-)

That said, a plugin interface would be really nice. At the moment I'm 
tempted to say that the plugins should be R packages rather than Cocoa 
bundles as they serve nearly the same purpose with the R package likely 
being less confusing for users. The problem is that it makes providing 
an interface to certain aspects of the R GUI more of a problem.


Having thought a little bit about it, here are things I'd like from the 
R GUI as a plugin author:

1. Some of the things common to a lot of plugins in a framework (e.g. 
RGUI.framework). This would include the Cocoa interface to the 
evaluator (REngine and friends) and the Quartz device (implementing it 
once was annoying enough :-P) are early candidates. It would obviously 
also hold a lot of the plugin interface information, such as 
notification constants and so on.

2. Support for both plugin modalities
	- "enhancements" which work through delegate and notification 
interfaces (or even internal AppleEvents, which seem to be important 
for certain types of scripting)
	-"replacements" which completely replace certain functionality, script 
editors, the console, data manager and so on. In fact, I would even go 
so far to suggest that the built-in GUI components be implemented in 
such a way to help develop the interface and provide a starting point 
of sorts for interested parties. There are some problems with this idea 
at the moment, particularly with the timing of console initialization 
(and I can imagine a situation where you would want to suppress the 
interactive console entirely), but nothing that seems insurmountable.

3. Support code for common tasks like merging menus and registering 
preference panes and loading Nibs located in packages. Fortunately we 
can do this in categories without much difficulty.

I suppose the best way to work this stuff would be to branch the GUI 
and begin experimenting with a plugin interface to see what is truly 
needed, what simply needs to be "by convention" and what plain doesn't 
work.

>
>> P.S. Using hints from DTL's RObjectiveC makefile this package uses 
>> Objective-C without requiring a patched version of R's build scripts.
>
> Well, except for you nobody used patched R for Obj-C ;P

Their loss, it was really quite pleasant. ;-) Of course, in this case I 
also needed to set the Deployment Target so I needed the Makefile 
anyway.

>
>>  With method swizzling, little packages have become my favored method 
>> of prototyping and providing GUI features for myself.... just in case 
>> y'all were interested :-)
>
> Indeed, that's what packages are for ;). It's about linking native 
> code to R. But for Cocoa, I'd use one of the Obj-C/R proxies for 
> prototyping, because it's much faster - no need to re-compile 
> anything... You really learn to appreciate interpreters when you test 
> small and dirty things :).

Yup, and I would have been able to make it a pure R package if there 
was a setHook() for "busy" too, but there wasn't, so down to Obj-C we 
go. (Sure, it means my code isn't threadsafe, but R I would bet on a 
"busy" setHook before threadsafety :-))

>
> Cheers,
> Simon
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian