-- This ticket was imported from http://sourceforge.net/p/rkward/feature-requests/110 on 2017-05-31 14:48:58 +0100 -- 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.-- Labels: Plugins --
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.