[RkWard-devel] 0.4.6+ and beyond: comments and ideas

[Prasenjit Kapat]

Hi,

On Sunday 18 February 2007 09:28, Thomas Friedrichsmeier wrote:
> Hi,
>
> On Saturday 17 February 2007 00:20, Prasenjit Kapat wrote:
> > Generic comments and ideas (I have written plugins for , but have NOT
> > committed them to svn yet.
>
> there's a word missing, here ;).

Yes, I forgot to mention which plugins I had written. Careless me. Anyway, I 
have committed a few codes today. I will explain them in the next mail.

> > [1] Set/Change default Working directory. May be under Settings > General
> > tab. Though this might as well go under, Console. Then change is from
> > Workspace menu, using setwd(). Ok, I have written a plugin which seems to
> > do the job. But it has some isues:
> >
> > The <browser> GUI element accepts type="dir" as a field. But, the the
> > dialog box DOES NOT accept directories, rather it accepts only files.
> > Moreover, the main button is a "Save" button, as opposed to "Open" for
> > type="file" field.
>
> Fixed.

Thanks, works fine now. 

> > Barring this, if you enter the directory name into the input box then my
> > plugin works. But, what would be better is NOT to use a plugin at all.
> > Rather hard code it into cpp (like how Open/Save Workspace works now)
> > which will be more intuitive. So ideally it would be realised as:
> > Workspace > Change Working directory > (Choose the directory using a file
> > open dialog)
> >
> > > Open > (Change/Add some message to either the status bar or the Title
> > > bar
> >
> > of the main RKWard window where the workspace name is displayed. )
>
> I'll add it to the TODO list. The idea about setting the status / title bar
> is nice, but I'll have to add some extra logic to make sure this info stays
> up-to-date, even if the user changes the directory by calling setpwd ()
> directly.

Great. Once this is implemented, we can remove my plugin.

> > [2] X11 Device export: We need separate plugins for exporting
> > postscript/pdf/png/jpeg. Using ghostscript (dev2bitmap) produces low
> > quality outputs. I have written a plugin for doing the png/jpeg export.
> > It is under Device > Export to PNG/JPEG. Again, it is no where near
> > complete but works. I am using dev.print(device=png,...) for this
> > purpose. I am planning to add two more plugins for pdf and ps, unless
> > someone else is already working on it.
>
> I'm not aware of anybody working on this, ATM. So go ahead!

Good. More on this in the next mail.

> > [3] CLT: This is one more "set of plugins" on my ToDo:
> > Now that preview rocks, I was wondering to add plugins to visualise, the
> > approach to Normality under CLT for different distributions. I am
> > planning to add it under Distribution > Beta > CLT. Suggestions for any
> > other appropriate hierarchy for these plugins and a proper label for the
> > meny entry are welcome. Of course, the foremost question is: Though this
> > is conceptually nice, whether such a plugin is needed for the current
> > project?
>
> Your guess is a good as mine, here. It's probably not the feature that is
> most urgently needed for most people. However, if you do the work, then you
> get to decide the priorities. On the other hand, if you're desparately
> looking for something to do, and don't have an idea, I'm listing some item,
> which I feel would be valuable in the short term at the end of this mail.
> Feel free to "claim" some of those, or to ignore them.

Well, I always had this idea about CLT plugin in my mind. And lately, a school 
project came up, where I can use this conviniently, so I thought may be I 
will write a preliminary plugin. Again, more on this in the next mail.

> Yes, window navigation is one of the things I plan on improving for the
> next release. F8 is not supposed to take focus from the console, however.
> It's meant to run the current selection. If the current selection is empty,
> and empty command gets run.

Yes, windows navigation shotcuts will certainly be useful.

>
> > [5] Remove "Preview" from TODO ?
> > 	- Preview of plots
> > 		- Maybe use a button (along the submit / close / etc. buttons instead)?
> > 		- The preview window should be a specialized RKCaughtWindow
> > 			- It should show info on state (up to date / updating / error / etc).
>
> What I meant by these cryptic note is some changes that could perhaps be
> done to the preview. "Maybe use a button" means, maybe there should be a
> toggle button below the "Close" button (or a checkbox at that place),
> instead of the current checkbox. The advantage would be, that for tabbed
> plugins, the preview-functionality would be visible on all tabs, instead of
> just the one it was placed on (typically the first). Not entirely sure on
> the merits, though. After all, this would mean one more button cluttering
> the UI.

I see. A preview button similar to the current Code button would be look cool, 
but I must admit the current implementation is quite good. 

> The other note means, that I think it would be better to show the info "up
> to date", "not yet possible", etc. in the preview window itself, instead of
> below the checkbox. Once again, this would make sure, it remains visible,
> even when switching to a different tab. Also, we could use some color
> coding, then (e.g. red for error, yellow for upating, green for up to date)
> to make this info more prominent.

That would be even nicer.

> > [6] 	- create grid() plugin
> >    I saw this in the current TODO file. What exactly is this grid()
> > plugin? Has this anything to do with Trellis grpahics?
>
> Stefan added this, so he's most qualified to comment. I understood it as
> plugin to add a grid to a plot (?grid or ?abline). Would likely be realized
> as an x11 device context plugin to modify an existent plot, but might also
> be a part of plot_options (or both).

Oh, ok.

> > [7] TODO: Implementing the Lattice (based on trellis) packge using menus.
> > Lets just keep this as a long term todo, not for immediate concerns. The
> > trellis graphics is one hell of a complicated but rather powerfull mess.
>
> Yes, feel free to add it to the TODO list.

Will do that.

> Some things that I feel would be very useful, while not too hard to
> implement in the short term (if you'd like to work on any of those, please
> send a short note, so there will be no duplication of efforts):
>
> - More help pages on usage of central components (and the applicable
> configuration options):
> 	- Workspace Browser
> 	- Script Editor
> 	- Command Log
> 	- Data Editor
> 	- "Plugins" (what they are, selection of .pluginmaps)
> - Full support for t.test()s
> 	- The current test could easily be extended to support paired samples as
> well (rename to "2 sample t test")
> 	- Single sample t test, i.e. test against constant value (should probably
> be a separate plugin, even though the needed code is very similar)
> 	- N samples t test (perform pairwise (two sided) tests for N variables)
> 	- Single var, N samples test (all measurements in a single var, using a
> grouping factor, i.e. stats:::t.test.formula)
> - chisq.test
> - working plugin for basic anova (this page:
> http://www.personality-project.org/r/r.anova.html might be a useful
> starting point)

Let me take some more time to decide on these :) 

Regards
PK