[rkward-devel] embeddable plugins [was: Select cases]

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Tue Nov 20 16:32:21 UTC 2012


Hi,

On Tuesday 20 November 2012, meik michalke wrote:
> Am Montag, 22. Oktober 2012, 21:02:37 schrieb meik michalke:
> > the plugin docs seem to concentrate on how to embed plugins, is there
> > also some documentation on what needs to be done to write an embeddable
> > plugin?

somehow I had missed the parent of this mail (marked it as read, without 
actually taking notice). I haven't quite made up my mind on your suggestions, 
there, BTW, although I feel I'd probably want to limit the number of 
subdirectories and single-plugin-pluginmap files.

Anyway, to your question:
 
> i'm still struggling with this. it wasn't too hard to find out how to
> actually embed the subset plugin, but after hours of trying i still didn't
> figure out how to pass a selected data.frame through to the embedded
> dialog. say:
> 
>  - plugin A is the embedding one, it has
>      - a varselector_A
>      - a varslot_A
>      - a button to embed plugin B
> 
>  - plugin B is the embedded subset dialog, it has
>      - a varselector_B
>      - an (optional) varslot_B
>      - the several subset options
> 
> now, what do i need to do to select a data.frame from varselector_A in
> varslot_A, an when i press the button, the variables of varslot_A become
> the root of varselector_B and varslot_B becomes invisible?
> 
> how would you do it if you wanted to embed the sort plugin?

Not sure, I understand the problem. If the plugin is embedded with id 
"embedded", you can access (and connect to) its properties as 
"embedded.property". Here, you could simply connect varslot_A.available to 
embedded.varslot_B.available.

That said, it is better to create a dedicated property for embedding plugins 
can connect to. That way you keep some freedom to change the implementation of 
your embeddable plugin, without breaking embedding plugins (think of it as a 
stable API):

   <external id="object" default=""/>
   <connect client="varslot_B.available" governor="object"/>

Then document that embedding plugins should connect to "embedded.object". 
I.e., in the embedding plugin add:

   <connect client="embedded.object" governor="varslot_A.available"/>

Sounds simple? Ok, I'm afraid it does get more confusing, after all. This is 
because, in your use-case, varslot_A.available is already connected to 
"current_object"(*). Connecting a property to several governors is typically 
not a good idea, as it makes it unclear, which property is actually in charge 
(and in face, without trying, I'm not sure, what would happen). I could think 
of several ways out of this situation.

Option 1: Instead of <connec>ting to "current_object", use <script>ed logic to 
initialize the varslot to the current object. I.e.: 

   <external id="object" default=""/>
   <connect client="varslot_B.available" governor="object"/>
   <script><![CDATA[
      // this will run only once, when the plugin is initialized:
      gui.setValue ("object", gui.getValue ("current_object"))
      [...]
   ]]></script>

Option 2: This is probably more clean, but also slightly more cumbersome: Make 
it so that your plugin is _always_ embedded, never standalone, and does not 
make use of "current_object". Then create a visible "wrapper" plugin which 
simply embeds this (as_button="false"), and only adds

   <connect client="embedded.object" governor="current_dataframe"/>

Finally: Making varslot_B invisible will need special-casing. You don't really 
want that varslot to appear and disappear every time you deselect / select 
something in varslot_A. Rather, you want this to be always invisible when the 
plugin is embedded. Perhaps the best way to solve this is going with option 2. 
Make varslot_B invisible by default, then, only when embedding in the 
"wrapper" plugin, set varslot_A.visible to true, from there.

(And no, I wouldn't be surprised, if I have confused you, completely, now. 
Just ask...)

Regards
Thomas

(*) BTW: You should connect to "current_dataframe", here. Currently, that's 
identical to "current_object", but in the future the first might be any type 
of object, while current_dataframe will always be a data.frame (or empty).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20121120/b65d84bf/attachment.sig>


More information about the Rkward-devel mailing list