[RkWard-devel] Plotting options

[I. Soumpasis]

2007/2/28, Thomas Friedrichsmeier <thomas.friedrichsmeier at ruhr-uni-bochum.de
>:
>
> 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).


I am reluctant to do this myself because after the two posts I made to the
R-help list I feel like the black ship. In the second post about pdf -
postscript diffs I got no answer. So please could somebody else ask?

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?
>
> I see the whole thing a little bit different way. I believe that some of
the options could be set by a plugin, eg las, and user could choose
according to his needs. But also some others like bg that must be defined or
like col,pch (according to my opinion) should (if it can be done) affect all
plots. The way I see it RKWard wil have something like a personal signature
and will differentate it form other apps. If this is the case we (the devel
team) have to decide about the bg color, the color of one color charts, the
shape of the points or whatever else, so to have homogenous plots. If we
managed to  change the default par options this would apply to the konsole
so to have something really homogenity, not just an option to the plugins.
If sometime we use lattice all these would not take effect for these plots
but it should be a special situation. I am looking at the par / plot
documentation but I am going a little bit slow.

It seems to me more like a marketing and a differantation issue.

I could not resist to attaching 2 pdf files which seem to me really great
but it is a matter of taste.

Regards,
Ilias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070228/ef7f2394/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rplot4.pdf
Type: application/pdf
Size: 7123 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070228/ef7f2394/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rplot5.pdf
Type: application/pdf
Size: 6058 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070228/ef7f2394/attachment-0001.pdf>