[RkWard-devel] RKWard development docs online

[Thomas Friedrichsmeier]

Hi David!

> Well, I just had a quick look at the documentation and at the source, which
> seem both fairly clear to me. Just a couple of things:
> 1. About the design overview: maybe listing the classes used in each part
> of the design could be useful (thus linking the overview with the technical
> side) ? A way to do this would be to embed it in the doxygen doc code, I
> suppose. I could try to do it (ie document the code), however I fear I
> would make many mistakes. OTOH it would help me getting in the codebase...

I suppose it would indeed be useful. Currently the API-documentation on most 
classes is in a fairly bad state. On many of the new classes I did not 
document much at all and on some of the old classes the documentation is 
getting outdated or even misleading due to undocumented changes. I'll 
definitely have to take a look at this soon.
And yes, it would probably be helpful to list the relevant classes in the 
design overview. In the current CVS-version I've reorganized the source-files 
into several directories, which should also help finding out, what all the 
files are about. I'll take the time to work on these aspects after the next 
release.
If you would like to start documenting the code, that would be highly welcome, 
of course, but note, that currently a lot is once again being changed (see 
below). One part that is currently somewhat stable is the plugin-related 
classes.

> 2. From what I've understood, the php backend could be easily replaced with
> any kind of interpreter (ie perl, python...). Do you support the idea of
> having several backends or are you definitely against it ?

Well, my position on this has in fact changed a bit. You may have noticed 
(depending on which version of the code you looked at), that I've introduced 
a new base-class "ScriptBackend", which the PHP backend inherits from. I.e. 
the rest of the code no longer needs to know anything about what kind of 
backend it's dealing with. This of course was done in order to make it easy 
to add different kinds of script-backends.
So yes, I think it may infact be worth trying out some different interpreters. 
Still it would probably make sense to use only one or two different 
interpreters, so as to keep dependencies low and maintainance of the plugins 
easy. I'm not entirely sure anymore, that PHP really is the best choice here.
So my position on this is: It may be worth the effort to try out some more 
different backends. We should not have tens of them, though. Maybe PHP will 
get replaced with something different.
This is not high on my agenda at the moment, so I won't work on it myself 
anytime soon, but if you're interested in adding a new backend - go ahead. 
I'll try my best to assist you with any problems that may arise.

> 3. Is there any way to directly enter R-code, ie some kind of editor and
> have it evaluated? Then goodbye emacs :-)

You can enter R-code in the bottom half of the R-Interface watch-window and 
have it evaluated using the "Run"-button. That interface is not very usable, 
yet (e.g. it loses focus all of the time), but it's there in principle. Read 
the "R-Command Editor"-section in the list of open tasks 
(http://rkward.sourceforge.net/devel/tasks.php) for some of my plans for the 
command editor.
One further problem is that R behaves somewhat differently in embedded mode 
than in normal operation. Most importantly, in normal mode, if you e.g. enter 
"x", R will print out the object "x". In embedded mode you have to enter 
"print (x)" explicitly to have the value printed. It should be possible to 
work around this, but those are some of the quirks you'll see for now.

> 4.  As to the wizard/dialog mode, I think wizard mode should be set as
> default.  Maybe it is not the case because Rkward is very much a work in
> progress?

Changing that setting is easy to do, and I don't have a strong opinion on what 
should be the default. Anybody else have an opinion on this? Otherwise I'll 
go ahead and change it.

Two further notes: 1) Right now I'm working on a new release that will put the 
internal workings of RKWard on a more solid foundation. An internal 
representation of the objects in the R-workspace is added and I'm currently 
working on putting it to use in the editor etc. The visible result of this 
will be that RKWard will be able to deal with several tables (though on first 
startup RKWard will still present you a single empty table like e.g. SPSS) 
and will allow you to inspect objects in the workspace. Quite a lot of 
classes are being touched, so I will delay documentation enhancements until 
things have stabilized enough for the next release. I hope to complete this 
work within the next few days.
2) You sound interested in joining the project, and I'd be very happy to 
welcome you (not trying to push you, though). If you would like to start 
working on some specific part of RKWard, just tell me. If you want 
CVS-access, you'll get it. If you'd like me to take a look at patches/answer 
specific questions, I'd be happy to do so.

Thomas