[RkWard-devel] Plotting options

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Wed Feb 28 18:53:08 UTC 2007


On Wednesday 28 February 2007 18:51, Prasenjit Kapat wrote:
> Then comes the question of setting 'default' par(...) configs. Should it be
> done globally from Settings > Configure RKWard > par() settings (another
> tab) ? Then read the default settings when initializing plot_options.xml
> (But such conditional approach in xml is not possible, or atleast not
> elegantly, I suppose)? So what solution, if any, for a modified 'default'
> set of par(...) cofigs, exists?

I think this may really be a whole bunch of issues at once (not suggesting any 
solution for now, just trying to sort this out in my head):

1) In this particular case, it's probably something that could and should be 
solved at the R level (see my other mail).

2) A further issue is: Should plugins "remember" the options that were 
selected the last time the plugin was shown? If so, is this desirable at all 
times, or should it be optional? How long should the settings be remembered 
(only for the session, or should it be saved across sessions)?

2b) How to deal with embedded plugins in this case? For instance, plot_options 
is embedded in plugins A and B. Should the plot options set in plugin A also 
be the ones that are "remembered" in plugin B? I guess in many cases this may 
be desired, but in other cases it is not, and may be pretty confusing (and 
for some plugins, like the color_chooser, this should probably never be done, 
as there may be several in use inside the same plugin). The alternative would 
be to keep the settings for plugins A and B completely separate, as though 
they did not share a common embedded plugin.

2c) Some options should likely be excluded from storage, for instance the 
variables selected for a test. How about other settings, like a vector of 
probabilities in a distributions plugin? How about graph/axis titles in 
plot_options? Can we figure out any patterns, or would this need to be 
specified in the plugin .xml?

3) Stored (named) default sets: In a different context, Prasenjit suggested to 
have a way to change several plugin settings at once according to a pre-set 
default. This might be a promising solution to several problems, if designed 
right. Some thoughts:

3b) It would probably be a good idea, if the user could "save" own default 
sets to be re-used later.

3c) What would be a reasonable scope of these sets? Perhaps everything with a 
window of it's own (regular plugins, and plugins embedded with 
as_button="true") could be the "group of settings" that could be saved / 
restored in this way. But perhaps other groupings would make sense in some 
cases (like only one page of a tabbed dialog)? How much fine-tuning should be 
allowed in order to provide something useful, but not having to specify too 
many details in a plugin .xml?

3d) How would this be realized UI wise?

4) Global defaults: For some settings it might be nice to have global 
configurable defaults. E.g. should the preview be on or off (if available)? 
Should NAs be excluded? Background color of plots? Without worrying about the 
C++ details for now, what would a GUI to set these look like? How would they 
be referred to in the plugin.xml? Do we really need them, or can we come up 
with a nice enough solution for 3)?

Thoughts / comments? Should we put something like this in the wiki for 
discussion?

Regards
Thomas




More information about the Rkward-devel mailing list