[rkward-devel] rkward on planetkde

[Thomas Friedrichsmeier]

Hi,

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.

True.

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

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

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

True.

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

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20090315/12ca6d6e/attachment.sig>