[RkWard-devel] RKWard development docs online

[Thomas Friedrichsmeier]

Hi!

> 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.

Ok, not vastly different as in no longer recognizable. But a number of things 
have changed all over the place, and yes, that's why it might be a good idea 
to wait a while.

> 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?

Difficult subject. I have not worried much about graphs yet, let alone 
interactive ones. I know, I want them, but I don't really know how to do 
this, yet. Here are some random thoughts:
1) Some of this functionality might be easiest to realize using R itself.
2) Currently the PHP-script for the plugin is re-parsed (or rather portions of 
it) whenever a change is made in the GUI. It's not currently visible or 
documented, but the script-backend can indeed make direct calls to R, so it 
could in principle modify a graph that is being displayed somewhere. Keep in 
mind, that the R-backend runs in a separate thread and might be busy doing 
some other stuff, when we want it to update a preview.
3) Certainly a lot of work will still have to go into this, and as mentioned, 
I have not even started thinking about it seriously. pyQt/pyKDE may be a 
viable option here, but it might not be the only one.
4) If you have a rough plan/idea on how to do this, I'd certainly be 
interested. Personally, right now I'm working on more basic stuff, but having 
a plan for the future is always a good thing.

> 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.

Interesting. What is it based on (if anything), what does it look like? Can I 
find it on the web somewhere?

> 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 :-)

Ok, you're right. Personally, when using RKWard, I'll probably switch it back 
to dialog, but as a default, wizard is probably reasonable.

> 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)?

Some reasons why I don't think it's such a good idea:
1) Unneccessarily complicated and detailed. The QTDesigner allows you to 
change font-sizes and background colors, spacings and margins (pixel-wise), 
etc. For plugins this is not really necessary or even wanted: It's rather 
desirable that all plugins somehow look and behave the same way. It may be ok 
to allow some formatting, but it should be done in a way that easily allows 
consistent changes. Lets separate content and design as much as reasonably 
possible. E.g. format "heading 1" would be fine, but format "Arial Black, 
20pt, Italic" may cause trouble. QTDesigner tends to the latter.
2) The ui-files are meant to be used to generate compilable C++-code. One nice 
thing about the current plugins is that they work entirely at runtime: Place 
a plugin in the plugins-directory, reload the plugins - done, no changes to 
the code required, not even a recompilation (admittedly, pyQt and possibly 
other tools can deal with ui-files, too).
2b) Over all, I think it's easier to create both a plugin-xml-format that does 
most of what will ever be needed (but is still kept rather simple) and some 
sort of "designer" for it, than it is to write an interpreter for all the 
flexibility that QTDesigner has and produces.
3) Theoretically (don't know if this will ever happen), it would be nice to be 
able to share plugins between different R-frontends. These will not use the 
same toolkits and might not even use C++. Hence some level of abstraction is 
a good idea, I think.

On the other hand, here's a sort of compromise:
I feel for most plugins the current format will do and is good, or extending 
it for further use cases is straightforward. However, there's no denying, 
that it cannot reasonable cover all the functionality we want. There will 
always be some things which are not easily doable in the current format. For 
those cases it will be best to hard-code them using Qt/C++ (or maybe pyQt!) 
directly. And for those, it would certainly be good to be able to use 
varslots and friends in QTDesigner. But that is an entirely different beast.

Thomas