[rkward-devel] data.frame-related plugins

[Thomas Friedrichsmeier]

Hi,

a few days ago, in private mail, Jacek asked me, how to access the currently 
edited data.frame from a plugin. The answer is that this is not currently 
possible, but of course it would make a whole lot of sense to be able to do 
so. Manipulating the current data.frame is a very important use case, and it 
should not be necessary to select the data.frame from the object list for each 
operation.

Some tasks that come to mind:
- sorting data
- generating data
- transforming data / recoding

Well, technically this issue is easy to solve. I'll simply create a new 
"context" 
(http://rkward.sourceforge.net/documents/devel/plugins/contextualized_plugins.html), 
which will be active when a data.frame-editor is active. Plugins in that 
context will be able to reference that data.frame.

What keeps me thinking, however, is how this plugin context relates to plugins 
outside of the context. Let's take the example of a plugin that creates some 
random generated data. The problem is, that there could really be three 
variants of this plugin:

1) A plugin that operates on the current data.frame, and adds a new column to 
it.
2) A plugin that operates on an arbitrary data.frame, and add a new column to 
it. I think this use case is important, too. Having to open each object that 
you want to work with, would seem rather cumbersome to me. And for very large 
data.frames, this could easily lead to serious memory/performance problems.
3) A plugin that adds a new object anywhere in globalenv(). This plugin would 
have to ask for the length of the generated sequence, but otherwise, it would 
be very similar to cases 1 and 2.

Again, technically this is not much of an issue. In fact it should not be too 
difficult to cover all three cases with a single piece of code. 2 and 3 could 
even be covered by the same dialog, invoked from the same menu entry. But that 
still leaves of with:

a) A dialog that can only be invoked when editing a data.frame.
b) A mostly identical dialog that is valid "globally", i.e. not tied to 
editing a data.frame.

So how to deal with this duplication of functionality? One approach would be 
to place all context-dependent plugins into sub-menus of "Edit". The global 
plugins would reside in some other top-level menu (perhaps "Transformations").

Another idea would be to have only one set of menu-entries, i.e. only "global" 
plugins. Those could still reference the current data.frame, if there is any, 
and work on .GlobalEnv, otherwise. Of course this would mean that the plugins 
change their behavior in a way that may be non-obvious and confusing. It might 
also be mildly infuriating, in case you really want to manipulate an object 
which is not the one you are currently editing (you'd have to close it, first).

What do you think of these options? Any other thoughts / ideas?

Regards
Thomas
-------------- 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/20100617/b6568725/attachment.sig>