[rkward-devel] rkward on planetkde

[Stefan Rödiger]

Am Sunday 15 February 2009 14:21:10 schrieb Thomas Friedrichsmeier:
> Hi!
>

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

Has anybody done this so far (or even succeeded)?

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

This sounds difficult and I doubt there are any developer resources yet.

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

If I get it right, this would make existing plug-ins obsolete. Or do I get it wrong here?

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

To be honest I can hardly contribute any suggestion about the future direction of the Plugins / 
Scripting. As a matter of fact a simple solution which is easy to learn would be great.

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

Would this get better with QtScript?

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

This is a lot of work. For sure badly needed. Again we lack resources here IMHO. Would you be so 
kind an send me (again) some notes how to work with the wiki (login, ...).

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

Well RKWard is a scientific tool and your proposal is actually the only way to go. Do we have the 
capacities? Volunteers?
Did anybody review a plug-in in the past and wants to share the findings?

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

(See above need more information "How to ...", I promised something like in the past but never did 
anything in the wiki.)

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

This means exactly?

> Eventually this could / should be 
> extended to allow automated testing of existing plugins.

automated always sounds good ;)

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

So far I felt quite comfortable with the help. But more "help" is better of course. However, I 
consider this low priority.

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

Who starts the discussion? And by plugin you mean the non-existing future implemetation?

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

This is really an issue. I use R/RKWard on regular basis at work an can tell this would really help 
allot to increase my productivity.

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

I missed two points. First is the office suite integration. I played with odfweave and sweave here 
and there but I fond all solutions to static so far. It's really hard to find a good way to 
exchange data/results.
Another issue which became more and more an issue for me is that everything has do be redone once it 
is finished. Plots are a good example here. Once the plot dialogue is closed one has to start from 
scratch. Errors during a workproccess happen but they are hard to correct without an undo option. 
But I understand that this is not easy to solve. But this is certainly something that I would like 
to see in the future.

Regards
Stefan