FARR v2 PLUGIN CREATOR (SDK/API) INFO THREAD

[mouser]

This thread will collect info and links for FARR v2 plugin writers:

• Download the plugin SDK (with sample plugin code) here: https://www.donation...ds/FarrPluginSDK.zip
• Download instructions and sample files for making your plugin updateable here: https://www.donation...kingAnUpdateFile.zip
• Thread on the forum discussing plugin ideas and requests: https://www.donation...dex.php?topic=8071.0
• Need more help? Ask me: [email protected]  or join the online irc-based text chat.
• Need a website for your plugin? Just ask!

Latest News:

• The plugin SDK pack was updated with sample DELPHI plugin framework (Sep 23, 2007) -- thanks to Okke.
• New plugin wrapper for C# by vitalyb can be found: here.
• An amazing plugin wrapper for Javascript and other Active Scripting Languages by dc member ecaradec: here - AMAZING

[Darwin]

Great! This should spur development of more plug-ins. I took a look recently at writing a plug-in and quickly realised that I was way out of my element depth. When I have time, I'll take a look at all of these resources and will take another crack at it 

[Okke]

I’m still working on the locate32 plugin and nitrix had some great ideas on how to use it.
Now I’m running into some problems.

What I tried to do:

-   used the regex “loc”
-   make an alias that does the following:
dosearch loc –p d:\music –ld $$1 +open_winamp

Why this doesn’t work:

FARR doesn’t seem to recognize the +open_winamp option when a regular expression is used.


What I tried to do next:
-   create an alias for the plugin named “locate”
-   make an alias that does the following:
dosearch locate –p d:\music –ld $$1 +open_winamp


Why this doesn’t work:

When using an alias and using the searchstring_lc_nokeywords parameter the options like “-p” and “-ld” get stripped too. So I can’t use that searchstring. It would also be really hard to distinguish minusoptions (for instance –mp3) that belong to FARR or belong to locate.


What I tried to do next:

Instead of having the locate alias use “-p” for directories and “-ld” for directories only, I filtered out the “+” options in the plugin so I can use the FARR searchfolders like “+folder_music” and options for directories only like “+\”. I open the FindAndRunRobot.ini and read the SearchFolders section to do that (Mouser, is there a way to question SearchFolders from inside the plugin?).

The options get translated back to the regular “-p” and “-ld” options and it loops through the matched directories and adds those files found to the results. Btw, people might say I could just return the results to FARR and let it do all the filtering in case of “+folder_music” but the problem is locate would just return ALL the results at first which is basically your whole harddisk .

This is working sofar but I’m running into one more problem. When I return the results I tell FARR to add a score to the files (also tried telling FARR to do matching after returning results as well). It does add a score but it totally seems to ignore pattern scoring. If I do “locate +folder_music +mp3 <artistname>” then locate returns the results but the “+mp3” pattern scoring doesn’t add the score to mp3 files. If I do “+folder_music +mp3 <artistname>” it does add the scoring. Does the pattern scoring work with aliases/plugins at all? I would expect FARR to apply the + modifiers to the result. In case of “+folder_music” and “+mp3” I’d expect all the results to match the first modifier and add the score to mp3 files that are found.

I could read the pattern scoring from the ini file as well but I’d rather not if it’s not needed. It would be great if I could just pass the results back and let FARR take care of the rest.

Mouser, do you have any ideas/solutions? Or anybody else ofcourse

[nitrix-ud]

[Select]

dosearch locate –p d:\music –ld $$1 +open_winamp

this is really hard to distinguish plugin parameters from FARR parameters...
this is also true for any other use of the dosearch command... application, alias, url

i feel that those parameters should be better separated maybe directly into the dosearch command :

[Select]

dosearch locate –p d:\music –ld $$1 [FARR]+open_winamp[/FARR]

or

[Select]

music search | dosearch locate –p d:\music –ld $$1 | +open_winamp

just my 2 cents

[mouser]

Okke,
these are great questions and points, just give me a day to get to them..

you've basically identified the crux of the problem, which is that on one hand the regex match blocks farr from stripping off and parsing the modifier options, and on the other hand if you don't use regex then all such modifiers and - arguments are stripped off.

one solution is to add a few options in aliases that let you tell farr what kinds of modifiers to strip off (-modifier and/or +modifiers), even before a regular expression match.

another solution might be in a non-regular expression match to let a plugin more easily examine the modifiers and tell farr which ones the plugin handled so farr doesn't have to.

[nitrix-ud]

Mouser, do you even read my posts ?

[mouser]

i replied to Okke's before i saw yours..

nitrix your idea is not a bad one at all, especially in the case of using the dosearch command.  in fact it would be pretty easy to add support for this with the dosearch command, which is a good idea and i should probably do anyway.

however it's not an ideal situation for when you want users to be able to manually specify modifiers, and some aliases may want to handle them differently than others.

[Okke]

@nitrix: lol, think Mouser has his nitrix filter turned on still

No problem Mouser, take your time.

Just to summarize the possibilities that would be really nice to have:

- make it very easy to distinguish between FARR specific options and program parameters
- be able to handle the modifiers with plugins, all of them or partially which means "+folder_music" could be handled by the plugin for instance, "+mp3" scoring by FARR
- maybe even the ability to let the plugin change the modifiers that are used? (would probably be more complicated)
- let the plugin have access to all the FARR options. Specifically the SearchFolders, Pattern Scoring and such
(less of a priority since I can easily load %APPDATA%\DonationCoder\FindAndRunRobot\FindAndRunRobot.ini and get the values from there if needed)
- being able to use modifiers on alias/plugin results. (For instance use locate to return a subset of 500 files which FARR filters afterwards with "+folder_music")

There are also some options in the plugin framework I'm clueless about when to use them and what they do precisely. Trying as much as possible with
trial and error to figure things out but I'll probably get stuck on some items

In the meantime I'll just try and find some workarounds.

[nitrix-ud]

  i was afraid you had me filtered out !

[Select]

nitrix your idea is not a bad one at all, especially in the case of using the dosearch command.  in fact it would be pretty easy to add support for this with the dosearch command, which is a good idea and i should probably do anyway.

however it's not an ideal situation for when you want users to be able to manually specify modifiers, and some aliases may want to handle them differently than others.

it is true that when using dosearch, nobody will really care about the length of what you type... which is a different story when using the search box directly...
i suggested not so long ago a second box next to the search box which would be the parameters box

using "dosearch" FARR parameters (+action, \STAYOPEN, etc.) would be clearly identified
and when using FARR search box, you would just tab (if tab autocomplete is unchecked) to go to the FARR parameters box ... (or click into the box) no need for "+" or anything else
one could imagine that there would be some kind of autocompletion like gmail (no need to remember the name of the modifiers... and much faster)

one other suggestion i already did was to better identify "folder modifier" from "action modifier", this is because it's pretty easy to run into problems...
for example if you give the same name to an action and an alias
or if you give the same name to an action and to a folder modifier...

i know that "+" is short and nice (though i do not like it... it is not direct on a laptop), but there are maybe other alternatives...
 
Keep up the good work, i guess there are just too much those days
Cheers, Nitrix


PS: oups, i forgot, it would be really really nice if one non-programmer like me could access as much information as possible to use it in a autohotkey script...
would it be hard to put informations into a standard window edit box, all those information presented one after another ??

[Select]

searchbox = my search
resultlist = result1,result2,result3
statusbox = statusbox  text
lastactivewindow = ...
etc.

as an example, i would love to have those information to be able to build a preview window for many of my aliases and in particular for my code snippet alias
you search for code snippet, autohotkey is triggered by the search box content (in my example : s keyword)
you select a result, autohotkey loads the content of the file... into a nice semi-transparent window... awesome 

[mouser]

Updated info with link to vitalyb's C# plugin code.

[mouser]

The latest FARR release (2.04.02) has added some new functions for plugins writers that have not been used yet in currently downloadable examples.  As soon as I finish adding a few more functions for the new htmlview in conjunction with plugin writers i will update the sdk documentation and examples.

[mouser]

Plugin writing tip:
To force FARR into showing all results for your plugin call: set_strval("setshowallmode","");

[phitsc]

The latest FARR release (2.04.02) has added some new functions for plugins writers that have not been used yet in currently downloadable examples.  As soon as I finish adding a few more functions for the new htmlview in conjunction with plugin writers i will update the sdk documentation and examples.

-mouser (June 09, 2008, 12:25 AM)

Any news on updating the SDK samples / documentation?

[mouser]

Meant to do it this weekend -- i'll do it tonight or tomorrow at the latest.