<br><br><div><span class="gmail_quote">2007/2/28, Thomas Friedrichsmeier <<a href="mailto:thomas.friedrichsmeier@ruhr-uni-bochum.de">thomas.friedrichsmeier@ruhr-uni-bochum.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Wednesday 28 February 2007 18:51, Prasenjit Kapat wrote:<br>> Then comes the question of setting 'default' par(...) configs. Should it be<br>> done globally from Settings > Configure RKWard > par() settings (another

<br>> tab) ? Then read the default settings when initializing plot_options.xml<br>> (But such conditional approach in xml is not possible, or atleast not<br>> elegantly, I suppose)? So what solution, if any, for a modified 'default'

<br>> set of par(...) cofigs, exists?<br><br>I think this may really be a whole bunch of issues at once (not suggesting any<br>solution for now, just trying to sort this out in my head):<br><br>1) In this particular case, it's probably something that could and should be

<br>solved at the R level (see my other mail).</blockquote><div><br>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? 

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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)?

<br><br>2b) How to deal with embedded plugins in this case? For instance, plot_options<br>is embedded in plugins A and B. Should the plot options set in plugin A also<br>be the ones that are "remembered" in plugin B? I guess in many cases this may

<br>be desired, but in other cases it is not, and may be pretty confusing (and<br>for some plugins, like the color_chooser, this should probably never be done,<br>as there may be several in use inside the same plugin). The alternative would

<br>be to keep the settings for plugins A and B completely separate, as though<br>they did not share a common embedded plugin.<br><br>2c) Some options should likely be excluded from storage, for instance the<br>variables selected for a test. How about other settings, like a vector of

<br>probabilities in a distributions plugin? How about graph/axis titles in<br>plot_options? Can we figure out any patterns, or would this need to be<br>specified in the plugin .xml?<br><br>3) Stored (named) default sets: In a different context, Prasenjit suggested to

<br>have a way to change several plugin settings at once according to a pre-set<br>default. This might be a promising solution to several problems, if designed<br>right. Some thoughts:<br><br>3b) It would probably be a good idea, if the user could "save" own default

<br>sets to be re-used later.<br><br>3c) What would be a reasonable scope of these sets? Perhaps everything with a<br>window of it's own (regular plugins, and plugins embedded with<br>as_button="true") could be the "group of settings" that could be saved /

<br>restored in this way. But perhaps other groupings would make sense in some<br>cases (like only one page of a tabbed dialog)? How much fine-tuning should be<br>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)?

<br>Should NAs be excluded? Background color of plots? Without worrying about the<br>C++ details for now, what would a GUI to set these look like? How would they<br>be referred to in the plugin.xml? Do we really need them, or can we come up

<br>with a nice enough solution for 3)?<br><br>Thoughts / comments? Should we put something like this in the wiki for<br>discussion?<br><br></blockquote></div>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.<br><br>It seems to me more like a marketing and a differantation issue. 

<br><br>I could not resist to attaching 2 pdf files which seem to me really great but it is a matter of taste.<br><br>Regards,<br>Ilias<br>