Author Topic: New FARR plugin : FSubScript enable loading of multiple javascript plugins (Read 55693 times)

ecaradec · « **on:** November 11, 2008, 10:18 AM »

FSubScript enable to load multiple javascript plugins in FARR without adding the FScript.dll for each. It should make it easier to write script plugins, share code between them and build a great FARR

The latest versions of FSubScript are maintained and improved by CZB. You can get it from the CZB with many plugins.
https://www.donation...ex.php?topic=17153.0

mouser · « **Reply #1 on:** November 11, 2008, 10:25 AM »

wha?!?!?!?!?!!?!?!?!?!?! ALREADY!!?!?!?!

ewemoa · « **Reply #2 on:** November 11, 2008, 10:53 AM »

Why do I need to go to sleep now!

FWIW, loads and works here

Oh, I completely forgot ... thank you so much!

Ampa · « **Reply #3 on:** November 11, 2008, 10:58 AM »

Wow - wow - wow!

This was unexpected - I thought that you might take a look over the weekend, and report back to us that the task was monsterously difficult, but that you might give it a go in the new year.

But no! Instead you whip up a complete solution and drop it on us like a 100 ton bomb of javascripting goodness

Congratulations on a supreme effort!

mouser · « **Reply #4 on:** November 11, 2008, 11:04 AM »

I think it needs a better name than "Scripter"..

Maybe EMSF (ecaradec's mutiscripter for farr)?
or FMS (farr multi-scripter)?

mouser · « **Reply #5 on:** November 11, 2008, 11:11 AM »

Couldn't get it to quite work here ...
i put Scripter and Colors both in a new parent directory.
Scripter was loaded by FARR, and it seems to have found the Colors script -- since if i typed scipter it listed "Colors"

but typing: colors

had no effect (just showed files with the word colors in them).

ecaradec · « **Reply #6 on:** November 11, 2008, 12:51 PM »

Sub-plugins are exposed as modifiers. You have to type : "scripter +colors". It also complete with tab.
I agree that scripter is a very bad name. I didn't change it because I hardcode it in many places.

I'll let everybody propose names for the plugins. FMS is nice by the way.

czb · « **Reply #7 on:** November 11, 2008, 01:23 PM »

Hi,
first of all, thank you for your share

.I have also been thinking of providing similar solution, but I was waiting if you are going to solve it on dll basis, since such a solution is javascript limited.

I am not familiar with how the plugin system works, but I guess dll basis might involve direct modifications of FARR as well, which might be long run development.

Another semi-solution which comes into my mind as non C++ programmer might be to create a dll file which would just point to a real fscript.dll. So the pointer would take fscript.dll as some kind of library. Then under any modification of fscript.dll, the pointer would remain unchanged.

ecaradec · « **Reply #8 on:** November 11, 2008, 02:00 PM »

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.

The nice thing is that it will allow to develop a librairies around the scripter plugin to help developpement of future sub-plugins.
The not the good is that all scripts are loaded in the same script engine (this is what will allow the first point ) and that means that plugins can interfer each others. It is relatively pointless to create plugins that would break the system so I hope that future plugins writers will take care of not breaking their environment. Currently plugins could remove others plugins, break them but also add them dynamically.

czb · « **Reply #9 on:** November 11, 2008, 02:22 PM »

Yes you are right that it brings quite significant advantages and can faster development of JS plugins.

For example I guess FARR update system will not work for it, but I can imagine script plugin to be used for new JS plugin installations, maintanace etc.

Well if you do not mind I can make my new goal to make kind of sofisticated JS plugin portal, or we can make it a colaborative work together with other JS coders (ewemoa etc)

mouser · « **Reply #10 on:** November 12, 2008, 07:17 AM »

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.

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 · « **Reply #11 on:** November 12, 2008, 07:21 AM »

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

mouser · « **Reply #12 on:** November 14, 2008, 02:02 AM »

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 · « **Reply #13 on:** November 14, 2008, 07:32 PM »

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 · « **Reply #14 on:** November 14, 2008, 07:41 PM »

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

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

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

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?

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.

mouser · « **Reply #15 on:** November 14, 2008, 07:42 PM »

One thing we should keep in mind -- i know ecaradec is doing a bit more work on this as we speak -- so it might make sense to hold off messing with the code until ecaradec is ready to pass the torch to someone else -- just to avoid duplication of effort.

ecaradec · « **Reply #16 on:** November 15, 2008, 06:31 PM »

I'm broke

I improved the now renamed FSubScript. There was some bugs in icons, results triggering, that should be now fixed. I also added a system to handle settings using ahk plugins. I made some improvement to make the scripts look like more like normal plugins. There might be bugs. There are centainly bugs.
However FSubScript begin to be usable. I'll let the dc community write all those wonderful plugins for farr that I hope FSubScript will help.

Tips :
- The new alias is fssc : for FarrSubSCript. Type fssc +colors to try the useless sample plugin.
- Don't define an alias for the plugins. It doesn't work currently. I need to use the groupname to identify subplugins and groupname is overwritten when an alias is defined.

See the links in the first post for downloading the last version.

ewemoa · « **Reply #17 on:** November 15, 2008, 09:46 PM »

Thanks for your continued efforts!

I had some fun pasting RGB triples

Hope to have something more substantial to add before too long.

ewemoa · « **Reply #18 on:** November 16, 2008, 07:28 AM »

Thanks ecaradec for:

function onProcessTrigger(path, title, groupname, pluginid, thispluginid, score, entrytype, args)

I am having more luck experimenting with file associations being handled by FARR (overriding / ignoring registry-based settings)

ewemoa · « **Reply #19 on:** November 16, 2008, 10:08 AM »

I put together a FSubScript plugin - Akete.

Briefly, this allows one to customize launching of files via FARR. A user can specify a file-extension -> executable association [1] via FARR's User Variable support. The archive contains a README.txt with details.

[1] Live free of the registry -- long live portable apps

mouser · « **Reply #20 on:** November 16, 2008, 10:17 AM »

FSubScript: i like the new name. And great progress!! The one thing i think is really key is being able to have the subscripts run using their own independent keywords and regexes.

ewe: going to try Akete right now. What is especially cool is that your script might be first plugin to actually take over launching of normal files, which would serve as a great example for others wanting to know how to do it.

mouser · « **Reply #21 on:** November 16, 2008, 10:19 AM »

Where do we put the scripts? in a subdirectory of FSubScript?

ecaradec · « **Reply #22 on:** November 16, 2008, 12:31 PM »

The one thing i think is really key is being able to have the subscripts run using their own independent keywords and regexes.
-mouser (November 16, 2008, 10:17 AM)

Do you mean configuring them ? or using them ?
I tried to use aliases for the independent keywords but it does not work right now because the alias replace the group name. This is why I needed to use the void parameters but it does not seem to work right now as I said. This would be nicer because it would allow the subplugins to look more like ordinary plugins

I put together a FSubScript plugin - Akete.
-ewemoa (November 16, 2008, 10:08 AM)

Felicitation you are a pionner of a new era

For your question in the plugin about the settings : One way to create options is to send a autohotkey executable, however you can do it the way you like. You need to send a message WM_USER+1 to the window name FScript/FSubScript. Autohotkey program can do this. However an IE with a registered custom protocol could do it to. UI in javascript is a bit tricky. I think I like the autohotkey solution the more.

I don't know if it is better to set script plugins in a subdirectory of fsubscript, or in a subdirectory of plugins or directly with other plugins. I like the solution 3 because it mean that it is a normal plugin. However, they are not normal plugin. It may not be a good idea. I'm not sure what's best.

mouser · « **Reply #23 on:** November 16, 2008, 12:35 PM »

i guess i dont know how to have a script actually be discovered by fsubscript..
it worked with early versions of multi script but not with current one.. when i bring up advanced options i just get empty list box.

i think it makes sense to have scripts be in subdirectory of fsubscript.

also i dont understand what you are saying about sending a windows message to fsubscript.

mouser · « **Reply #24 on:** November 16, 2008, 12:52 PM »

ok i see why it wasnt finding the subscripts -- you have it looking in one directory deep inside the parent directory.
moving the scripts to the main Plugins directory makes it work.

i'll note that if you make it search arbitrarily deep in the parent Plugins\ directory, it would find subscripts whether they are in their own top level plugin directory, OR subdir of FSubScript, which would be nice and handle all cases.