[rkward-devel] rkward on planetkde

[Stefan Rödiger]

Am Sunday 15 February 2009 14:21:10 schrieb 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

Regarding item 1.

I have added Meik and Roy to the author list (main.cpp / KDE4).

Regards
Stefan