[rkward-devel] Subset plugin; Release plans

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Mar 15 10:50:48 UTC 2013


Hi,

On Wednesday 13 March 2013, meik michalke wrote:
> Am Mittwoch, 13. März 2013, 17:38:01 schrieb Thomas Friedrichsmeier:
> > However for generating non-trivial .js, the extra language layer is
> > making things more confusing, not less. Not sure, whether/how this could
> > be improved (and that's for another day, anyway).
> 
> you're right, i'm not completely satisfied with that part myself. you can
> still paste the JS code as plain text with rk.paste.JS(), and just use
> things like id() to get the correct ID. or you can remove "js" from the
> "create" option of the final rk.plugin.skeleton() call and write all of
> the JS files yourself. the package was designed not to force you into
> using functions like ite(), echo() and the like.

well, when writing the JS file completely stand-alone, you're left with the 
problem of getting the correct ids. So I've inlined the JS in a large id() 
call. That still leaves some problems with quotation (esp. proper escaping of 
"\n" and "\t"), and of course you don't get syntax highlighting while typing, 
but I think the result is a lot less mind-twisting, IMO.

> oh, did you try to set "tests=TRUE"? it will generate a template for
> plugintests, which is hopefully of help. a template for a help page can be
> added by adding "rkh" to "create" (there are also rk.rkh.* functions in
> rkwarddev to write the full help page in the generator script), and setting
> "edit=TRUE" will load all generated files in RKWard editor tabs.

I've added the subset plugin to data.pluginmap to make sure it's visible 
during the release testing. Plugin tests and help file to be added.

I did not find the time to work on a more flexible solution with an 
<optionset>. I guess that will also mean splitting the plugin, to keep UI-
complexity managable. Some further TODO and wishlist items are listed at the 
top of the rkwarddev-script.

I'm not sure, how we will manage (re-)generating .xml, .rkh, .js files when 
changing a scripted plugin. Ideally, we'd have some scripted (possible R-
scripted) magic to take care of everything. For now it's a manual process. I 
guess pluginmaps will continue to be managed by hand.

In the generated .xml-file, I noted that this tries to include the containing 
.pluginmap. I guess that's for <about> and <dependency> info? Please don't do 
this. If no per-plugin <about> data is specified, it is inherited from the 
.pluginmap, automatically. If there is per-plugin <about> data, it should be 
listed in the plugin, itself. If you want to share <about> data, explicitely, 
place it into a separate file of its own, which you can include in both 
.pluginmap, and .xml.

Also, while working on the rkwarddev script, I ran into problems with 
duplicate ids assigned to elements with similar labels. Here's a somewhat wild 
thought for a possible solution: If scripts are usually warpped into local(), 
anyway, why not use a custom wrapper function, e.g. "rkdev.scope()", instead. 
This would create an internal object current_scope_ids in the rkwarddev 
namespace. All rk.XML.*-constructors would register their ids in this variable 
(if it exists, i.e. if called inside rkdev.scope()). rkwarddev:::auto.ids() 
would consult this object to check for dupes (and probably use make.unique() 
to fix problems).

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


More information about the Rkward-devel mailing list