DonationCoder.com Software > FARR Plugins and Aliases

New FARR plugin : FSubScript enable loading of multiple javascript plugins

<< < (3/12) > >>

mouser:
This is a FScript based plugin. Sub-plugins are in fact plugins for the scripter plugin, not directly FARR plugins. There isn't any support for regex based search, and I'm not sure that I could add it.
--- End quote ---

Having looked at the code.. it really doesn't seem that hard to add all of these things:
1) regex support for each plugin
2) custom icons for each plugin
3) ability to disable and enable individual scripts

Because in essence you've showed how to make a set of functions as an array element that can be iterated through.
For example instead of using plugins["colors"]={..code..}
It could be done like plugins["colors"]["regex"]= "color .*" and then plugins["colors"]["icon"]="coloricon.ico" and plugins["colors"]["code"]={ .. code..}

Am i wrong?

And as for update support -- that's not a problem at all -- the updater doesnt care if it finds 20 different .dcupdate files in a plugin directory, so each little script can have its own update file.

mouser:
One downside.. this only works for javascript not the other fscript supported languages.

mouser:
ecaradec has gotten us started with this and shown us the way to multiscripts.. now we need a javascript coder to pick up the ball and run with this.. to extend the concept to allow:

* each script to have its own regex pattern matching
* each script to have its own icon, description, help
* each script to be able to implement custom trigger handling
* some sort of script management to allow scripts to be enabled and disabled

ewemoa:
I'm willing to start taking a look.  To be frank though, I'm not clear currently on how all of the points you mention might be carried out.  Perhaps some of the details can be discussed here?

Below is an attempt at following up on some of the points mentioned so far.


* The per-script icon, description, help, and .dcupdate seem straightforward as you have already described.
* Do you think script management would be a matter of tracking an enabled/disabled value per script?  Is there an issue with asynchronous processing?  How might enabling/disabling a script be affected by this?
* As far as UI is concerned, a simple starting point might be a dialog box appearing via Scripter's "Configure Advanced Plugin Options" button.  However, does it seem doable to achieve per-script configuration via the Plugin Manager dialog box (at least eventually)?
* I'm in the dark about regex pattern matching for each script.  Storing and referencing a regular expression string per-script seems straightforward, but how the resulting regex is used by Scripter to work with FARR is not clear to me.  If someone already has a clear idea of what to do, I'd be happy to hear it :)
* I didn't understand what you meant by "custom trigger handling" -- does this refer to onProcessTrigger(), onReceiveKey(), and the like?

mouser:
I didn't understand what you meant by "custom trigger handling" -- does this refer to onProcessTrigger(), onReceiveKey(), and the like?
--- End quote ---

Yep.  Basically the parent script has to iterate through each of the multiscripts and see if any want to handle each call.


I'm in the dark about regex pattern matching for each script.  Storing and referencing a regular expression string per-script seems straightforward, but how the resulting regex is used by Scripter to work with FARR is not clear to me.  If someone already has a clear idea of what to do, I'd be happy to hear it
--- End quote ---

Again basically the parent script needs to take each RAW search, and iterate through each of the multiscripts and see if any of them should handle it based on their own regex match.


As far as UI is concerned, a simple starting point might be a dialog box appearing via Scripter's "Configure Advanced Plugin Options" button.  However, does it seem doable to achieve per-script configuration via the Plugin Manager dialog box (at least eventually)?
--- End quote ---

I think we are on the same page.. basically when user says to do advanced config of the parent manager script, it should show a page of options.  this page might look like a checklist box of each multiscript plugin found, where individual scripts could be enabled or disabled.

If individual plugins wanted to have their own options.. there would be a few choices.. you could have a button next to each multiscript to show *ITS* options, or maybe a simpler method would involve each mutliscript providing some html text with some form inputs that would be for that scripts options, and the multiscripter would present all form htmls on one page.  And then let the multiscript save all the variables using the new UserVars option in FARR.

This is the most confusing and advanced part of multiscripts and i think for now these options ideas can just be ignored for version 1.


Do you think script management would be a matter of tracking an enabled/disabled value per script?  Is there an issue with asynchronous processing?  How might enabling/disabling a script be affected by this?
--- End quote ---

I really don't see any issue here -- all you are doing is telling the mutliscript supervisor to ignore certain scripts and not even bother to call them with a chance to match search or trigger result.. shouldnt be a big deal.

Navigation

[0] Message Index

[#] Next page

[*] Previous page