[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