[RkWard-devel] RKWard development docs online

[David Sibai]

Hi!
> 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.
Does this mean that the CVS code is vastly different from the 0.22 release? If 
so, I think it would be better for me to wait for an API-stabilization. 
> 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 agree with you on this one. Having tons of dependencies is usually not a 
good idea!
> 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.
I think I'm going to try to add  a python backend. Have you considered the 
possibility of "dynamic" plugins? That is, plugins (for example) which would 
output a graph (for example) which the user could then change/zoom by 
clicking around. I believe this is not feasible right now, however maybe with 
python+pyQt/pyKDE this would be possible? 
I have already written a plugin-oriented statistical application (quite close 
to yours actually, but more Splus-like) in python, and in my experience, it's 
very usable. 
>
> 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.
Ok, I'll have a look.
>>wizard/dialog mode:
> 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.
I just thought it should be the default since (from what I've understood) 
rkward is meant to be a very easy and clickable statistical software. And 
this is just what the wizard does :-)
> 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.
I think I'll start slowly and try to create a few patches. I'll get the CVS 
and start hacking around.
As to the xml description of the interface, so far you've been rewrapping the 
various qt widgets. Do you think it would be possible to simply reuse the ui 
files generated by QTDesigner, with a couple of tweaks (varslots as new 
custom widgets)?



David