[rkward-devel] rkward on planetkde

[Thomas Friedrichsmeier]

Hi!

On Tuesday 10 February 2009, Roy Qu wrote:
> Good article!
> I wish thomas could make some spare time to make a roadmap / feature plan,
> then
> we could see if there is anything we can do to help push the development of
> rkward forward.

Point taken. Problem is, there is no real roadmap. You'll find an unsorted 
collection of planned features in the TODO-file, and the feature request 
tracker. But here's a short list of the major areas that I think should be 
dealt with, next:

1. Make (a) new release(s). This is definitely step 1 of any roadmap. Pretty 
important to get the recent fixes out into the world, soon. What needs to be 
done is basically:
	- Make sure, the ChangeLog is complete
	- update .po files, if available
	- Add Roy in the credits (main.cpp)
	- Create test release
	- Test
	- Create final release
	- Write some short notes for
		- rkward.sf.net
		- apps.kde.org
		- freshmeat.net
		- rkward mailing lists
	- If possible, update the debian-files

Creating (test-) releases is fairly easy for KDE4: Just run the makedist.sh 
script with the version name as parameter. For KDE3 there is a long and 
illogic procedure to follow. It's probably much easier to me to just do it, 
than to explain it, so I'll try to find the time, soon. For KDE4, it would be 
great if somebody could give it a try, so you'll be able to jump in again in 
the future. If (when) you run into problems like lack of permissions or 
whatever, just ask - I'll try not to take too long in responding.

2. Create a Windows-port. I think it is important to address this in the not 
too distant future, but it probably isn't the most reward task to get started 
with. If you do feel like giving it a try, the main steps are:
	- (Get a KDE development environment running on your Windows box)
	- There is quite some platform dependent stuff in the startup code of R (much 
of it for no good reason, it seems). Cope with that in rembedinternal.cpp.
	- Review the code for system specifics, esp. bash commands (grepping for 
QProcess / KProcess should show the places in question), and perhaps path 
separators in some places.
	- Find a solution for the graph windows. This may well be the most difficult 
step, though it should be solvable somehow. Perhaps at first, the 
whole "windowcatching" mechanism would need to be disabled in order to make 
the rest of rkward compile.

3. Plugins / Scripting: We've touched the subject in the past: The plugin 
system needs better scripting. The likely candidate would be QtScript. This 
task will need to be addressed very carefully, since design decisions at this 
point will be very hard to change later on. I think this task can roughly be 
divided into the following steps:
	- Create a QtScript-thing which basically does what the PHP-script engine 
does - i.e. generate the preprocess / calculate / printout code-segments when 
called from C++.
		- As a first test, implement the color-picker mini-component with this 
engine. Watch out for potential performance issues in the graphing plugins.
	- Expand the solution to allow manipulation of "component-properties" from 
the script. I.e. create a replacement for the cumbersome "logic"-section of 
current plugins. At this point it is important not to add too much. The main 
point to consider is to enforce keeping the plugins as modular as possible. 
Esp. it should be impossible (or a least very hard) for a plugin to 
manipulate a plugin it is embedded in, or that it embeds.
		- To test the design and implementation, try to re-implement the 
plot-options component with this solution. At this point, extensive review of 
the design should follow.
	- Finally, allow creating complex GUI-elements by QtScript. The important 
point to keep in mind is once again to keep things modular: Such GUI-elements 
should be embeddable by other plugins, and should be re-used as much as 
possible.
		- Sample implementations might be: A chi-square-table input tool, a more 
elaborate color picker complete with color wheel, etc.

4. Plugins / Development process: The most important area of growth in rkward 
will need to be the plugins. By now we have a good hand full of people who 
know how to create plugins. What we really lack is a good review process. 
There are still a number of plugins waiting for inclusion, and we need to 
make some progress at this point. For now, I propose something along these 
lines: Create a table (in the wiki or somewhere else) with the plugins as 
lines, and several columns:
	- Usability / Layout of the GUI
	- Correctness / readability of plugin .xml
	- Correctness / readability of plugin .php / script
	- Correctness / readability of generated R code
	- Correctness / readability of output
	- Correctness / readability of help page
	- Overall correctness (of calculation / does the right thing)
Before inclusion in an official release, each column should be signed off by 
at least one reviewer (other than the plugin author), the "overall 
correctness" column by at least two reviewers. It should be considered good 
practice to have two signatures in each of the columns, though, and as many 
as possible in the "overall correctness" column.
Very complex plugins may need to be divided into several portions (rows). The 
main idea behind this suggestion is that the review-process should be more 
formalised, and at the same time divided into more managable small tasks.
Of course all of this is entirely up to discussion, and can be adjusted as we 
go, but I think we should give it a try. If you want to help, the first step 
is to create such a table in the wiki, list the plugins needing review, start 
reviewing, and ask others for help, where needed.

5. Plugins / Automation / Testing: It would be great to be able to invoke 
rkward plugins (with certain settings) automatically, from R code. This 
should be quite possible to implement. Eventually this could / should be 
extended to allow automated testing of existing plugins.

6. Better help integration:
	- Integrate more R help ressources into rkward (vignettes, R wiki, etc.).
	- Make rkward-help pages searchable, preferrably using a common search 
interface with the R help search.

7. Internationalization:
	- Find a good solution to make plugins and plugin help pages translatable. 
Probably you will need to discuss with i18n-experts (from KDE or elsewhere).

8. Create editors for more R data structures, esp. matrices, and vectors, and 
add support for R data types such as dates. Particularily vectors should be 
relatively easy to implement on top of the existing editor-code, and will add 
a lot of value to users.

Ok, those are the "main" points, I can think of right now, but of course they 
do not need to be addressed in this particular order (except perhaps point 
1). Also, there are many, many small things worth addressing, so if there is 
an itch that needs scratching, go ahead and scratch.

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20090215/a7a475b2/attachment.sig>