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 ------------------------------------------------------------------------------ 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 RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
