[rkward-devel] rkward on planetkde
thomas.friedrichsmeier at ruhr-uni-bochum.de
Sun Mar 15 13:23:01 UTC 2009
On Thursday 05 March 2009, Stefan Rödiger wrote:
> Has anybody done this so far (or even succeeded)?
not as far as I am aware. I meant to do some of that, but - will I ever
finally get around to do something again... Hang on...
> > 2. Create a Windows-port. I think it is important to address this in the
> 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?
Only partially. The .rkh files are entirely unaffected by this. The .xml files
will continue to work as is, but using QtScript will add some new
possibilities. Most importantly, some very complex "logic"-sections (such as
in plot_options.xml) *can* be rewritten in QtScript. This should allow to
rewrite some plugins in a more readable and manageable way, but all old .xml
files will continue to function without changes.
One thing that would become obsolete (but only in the longer term; this will
continue to be supported for some time) would be the .php-files. The
dependency on PHP is quite heavy, and I think it would be a good idea to get
rid of it in the long term. However, most of what we have in the .php-files
right now should be very easy to map to QtScript. Probably the majority of
our plugins can be converted using simple search-and-replace operations.
Where manual work is needed, it will still be much easier to adjust an
existing .php file to QtScript than to develop a new plugin from scratch. So
time spent on developing plugins using "old" php technology is *not* wasted
> > 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?
It may get slightly better, but probably not much. We would no longer need to
mention PHP, which did scare away some few people in the past, I think. Also
*some* things would become easier, but as detailed above, most things would
remain more or less unchanged.
> > What we really lack is a good review
> > process.
> 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, ...).
I'll send you a password in private mail in a few minutes. Unfortunately,
the "E-Mail Password" button of the wiki itself is broken.
> > 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?
Someone with C++-coding skills should be able to implement this within a
reasonable amount of time. This might be a nice task for someone who would
like to started getting involved with RKWard C++-code.
> > 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
This discussion can be started by anyone. I don't plan to make any specific
proposals any time soon.
The transition from PHP to QtScript may or may not change some technical
aspects of an i18n-implementation, but not in a way that should stop us from
starting the discussion.
Sub-questions of this task (in roughly the order they need to be addressed):
- Which strings actually need to be translated in .xml, .rkh, .php files?
- Can those strings already be identified automatically (e.g. in .xml files,
any attribute called "label" is a translatable string), or do they need to be
marked as "translatable", manually?
- How should the strings be presented to translators? How much context is
needed, and how should be context be given?
- How exactly can the strings (and context) be extracted automatically?
- Will i18n strings from plugins be collected in one large or in several small
- How will the i18n lookup be implemented in C++?
> 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.
Good point. This second issue somewhat related to "automatic invocation of
plugins" above. We could keep a list of which plugins have been run, with
which settings (in the output, or elsewhere), and offer a simple right-click
option to open the plugin-dialog with the same settings again. That's not
quite an "undo"-option, but it would simply make "redoing" something much
more easy. (And this should not be too hard to solve for a C++-coder.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the Rkward-devel