DonationCoder.com Software > FARR Plugins and Aliases

FSubScript Feature Requests

<< < (4/5) > >>

ecaradec:
I upgraded the last fsubscript with new fscript.dll that support onprocesstriggerv2. onprocesstriggerv2 will be triggered on selection of items, context menu, tab completion. Since there is few plugins on fsubscript currently may be we could break compatibility and only support this new version when this version of FARR goes public ?

mouser:
this is exciting! im looking forward to seeing what context menu plugins people come up with.

I upgraded the last fsubscript with new fscript.dll that support onprocesstriggerv2. onprocesstriggerv2 will be triggered on selection of items, context menu, tab completion.
-ecaradec (December 20, 2008, 02:38 PM)
--- End quote ---

ecaradec:
How can we extend context menu mouser ? Is there some setStrValue or something ?

ewemoa:
FWIW, below is a segment of code that seemed to work w/ latest alpha from mouser and latest fscript.dll from ecaradec.


--- Code: Javascript ---// trigger modes      TM_NONEXPLICIT = 0, TM_EXPLICIT = 1, TM_PREPARECONTEXTMENU = 2,      TM_RESULTSELECTED = 3, TM_TABBED = 4;  // ...  function onProcessTriggerV2(path, title, groupname, pluginid, thispluginid,                               score, entrytype, args, triggermode) {    // ...    if (triggermode === TM_PREPARECONTEXTMENU) {      FARR.setStrValue("addmenu.contextmenu",                       "type=item|caption=MyTest|hint=this is hint|icon=help.ico|launch=restartsearch help");    }

czb:
Hi,
reading about future extension system of chromium I think we should use JSON manifest in our plugins.
For more info take a look here:
http://dev.chromium.org/developers/design-documents/extensions/manifest-format

Chromium is going to use manifest in a separate file so I woul like to discuss here if it is reasonable to have manifest in a separate file or not.

Here is my thinking:
* From the coding perspective it would be good to have one file scripts only (so to have in the same file manifest + code)
** Then there must be a clear distinction between manifest and the code so we would be able to match manifest inside a string
* Manifest in a separate file would be easier to implement but would cause 2 file scripts which is unpreferable
* Now the situation is chaotic because there is no Manifest and for fssc purposes the description and name is retrieved by loading entire string and regex matching of the info. This might bring future incompabilities.

So if we did:
plugins["name"]{
  manifest:{
    displayName : "Test",
    description: "description manifest: {} function() and other dangerous stuff",
    icon: variable + "string.ico";
    Author: "String"
  }
}

we probably would be able to write a regex to match the manifest object and then to evaluate it.

Another idea might be to use file description system (right click on JS file). But I am not familiar with it so I do not know how safe it would be

Any ideas are welcome

Navigation

[0] Message Index

[#] Next page

[*] Previous page