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
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
_______________________________________________ RKWard-devel mailing list RKWardemail@example.com https://lists.sourceforge.net/lists/listinfo/rkward-devel