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