[rkward-devel] Request for feedback on new plugin features, and plot history

[Stefan Rödiger]

Am Dienstag 03 August 2010, 13:55:39 schrieb Thomas Friedrichsmeier:
> Hi,
> 
> I had meant to write this mail much earlier, but never found the time: The
> current development version has some new features which we need feedback
> on. You can get it from SVN as usual, but if you're running Ubuntu or
> openSUSE, you can also find compiled packages at
> https://launchpad.net/~rkward- devel/+archive/rkward-devel and
> https://build.opensuse.org/project/show?project=home%3Atfry-suse%3Arkward-
> devel , respectively.
> 
> --
> 
> The first area that needs some testing and feeback is the plot history
> feature which Prasenjit has added to the graphics windows. Basically,
> please create a few plots in one or more windows, try the toolbar buttons,
> and comment on any aspect that is not intuitive, or buggy. Prasenjit, if
> you have a bit of time, could you summarize the remaining questions,
> again?
> 

I used the plot history (svn). So far I have no problem to understand or use 
it. There were no crashes, toolbar button and so on worked reliably and 
intuitive. 

> --
> 
> The second area that I would like to pick your brains about is some new
> plugin features. Perhaps you recall this short thread on how to deal with
> plugins that do data.frame specific transformations: http://www.mail-
> archive.com/rkward-devel at lists.sourceforge.net/msg00779.html . The
> development snapshots have some variants of a solution for that. To try
> it, frist make sure that the under_development.pluginmap is activated
> under Settings-
> 
> >Configure RKWard->Plugins.
> 
> You should see a new top-level menu called "Data". In this, there are two
> variants of a "Sort data" plugin, and you will want to try each
> a) while you are editing a data.frame, and the data.frame is the active
> window and
> b) while any other window is active.
> As you will see, in case b), both plugins will seem identical. In case a),
> the active data.frame is preselected in both plugins, but the first
> variant still allows to select a different data.frame to sort.
> 
> Key questions on that:
> - Which variant of the plugin is preferrable?
> - Do you think it is intuitively clear, when a data.frame is "active"?
> Suggestions for improving this?
> 

I have no preference. Both are fine for me.
So far I had no real world scenario to make use of them and thus no suggestion 
or objections.

> You may also want to look at the "Generate random data" plugin. Here, when
> a data.frame is active, the generated data will be added to that
> data.frame by default. When no data.frame is active, the generated data
> will be added to the .GlobalEnv by default. In both cases, the
> <saveobject>-element at the bottom allows to select a different place to
> save to (which is new, as well).
> 
Nice too. Again, I had no real world scenario to make use of it and thus no 
suggestion or objections other than to state it works.

> Finally, plugin developers will be interested in taking a look at the
> technical side of these plugins. The code for them can to be found in
> plugins/data. You will see note two things:
> - The active object (currently data.frames, only) is available from a
> property called "current_object". If no object is active, this is an empty
> string. - There is a <script>-block, which allows scripting of the dialog
> itself, instead of the generated code. Here, it is mainly used to check
> whether or not the selected object is a data.frame. I hope you can figure
> out the meaning of the code in the <script>-block yourself, and if you
> can't, that probably means I need to change things.
> 
> One further plugin to show some more possibilities of plugin scripting is
> in Analysis/QtScript Test 1 (code is in plugins/tests). I suppose this
> will be particularly interesting to Meik, who has been asking for similar
> functionality in the past. Please let me know what you think (since this is
> totally undocumented ATM, you may want to take a look at
> scriptbackends/rkcompnentscripting.js as a reference of implemented
> functionality).
> 
> Well, take your time, we don't need to rush decisions on any of this, but
> it would be cool, if you could take a look at these new features, and
> share your thoughts.
> 
> Regards
> Thomas

Regards
Stefan