[rkward-tracker] [ rkward-Feature Requests-3448066 ] Global storable settings for use in plugins

[SourceForge.net]

Feature Requests item #3448066, was opened at 2011-12-02 01:13
Message generated for change (Comment added) made by m-eik
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=3448066&group_id=50231

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Plugins
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Thomas Friedrichsmeier (tfry)
Assigned to: Nobody/Anonymous (nobody)
Summary: Global storable settings for use in plugins

Initial Comment:
E.g. location of auxiliary executables such as perl, which might be needed in plugins.

Basically, I can see two strategies. Not sure, which is best, yet.

1) Implement this entirely in the frontend, using a special element in the logic section, which can be connected à la:

    <storedsetting id="perl_exe" setting_id="perl_exe" label="Location of Perl executable" type="exe"/>
    <connect governor="perl_exe" client="perl_exe_input.text"/>

This would raise a number of follow-up questions, though:
- Should a stored setting take precedence over a setting defined in a run-again-link?
- Should the value be saved automatically when used? How?

2) Implement this on the R level. Main function to be used in plugins would be something like:

rk.get.plug.option <- function (id, label, default, type=c ("exe", "string", "number", "custom"), validation=function () TRUE) ...

Basically, when this is called, it will look for a stored setting (or take the default, if specified). If this passes the validation (defined by "type" or "validation" function), it will be used. Otherwise, the user will be prompted for a setting, interactively, using rk.show.question(). If a new setting is supplied, and is valid, it will be stored.

----------------------------------------------------------------------

>Comment By: m.eik (m-eik)
Date: 2011-12-04 10:55

Message:
funny, i was thinking about such a feature a while ago, too ;-) the koRpus
plugin needs info on where TreeTagger is installed, and it's pretty
tiresome to define it again and again.

couldn't this be stored in a special section of the RKWard config file?
perhaps similar to a run-again-link, and if it's found, a plugin will be
started with these parameters, not the original default values. that way
nothing would need to be changed in any plugin, it would be more like an
additional layer RKWard would check before a dialog is started.

i think run-again-links should always overwrite these settings, otherwise
they'd become quite useless compared to the usual menu entry, wouldn't
they?

as for the interface, i'd prefer two global buttons, next to where the
submit and code buttons are now: one to "set as default", and one to
"restore defaults" (which means the original plugin defaults). the latter
shouldn't remove the cusomized defaults though, only if you press "set as
default" again afterwards.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=459010&aid=3448066&group_id=50231