Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

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"

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.

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.

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.

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 plugin2) custom icons for each plugin3) 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.

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?

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?

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.

Quote

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.

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.

Quote

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.

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.

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.

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.

The one thing i think is really key is being able to have the subscripts run using their own independent keywords and regexes.

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

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.

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.

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.