FSubScript Feature Requests

[mouser]

I thought it might be useful to start a new thread for feature requests and future work discussion of the amazing FSubScript multiscript plugin which is described here: https://www.donation...ex.php?topic=15686.0

I'll start off with a major and minor feature idea.

Major one:
This is not restricted to FSubScript, but could be used by other plugins and even aliases.  The idea is to have a system by which it would be easy to let users customize options for a plugin by simply letting the plugin writer design a simple html form that was shown in the embedded html result mode, and have farr auto populate the values and auto save them using the new User Variables fields.  This would make offering options for a plugin or alias 1000x easier than it is now, for both coder and user.

Minor one:
Define some variables in the subscripts like author, version, description, webpage, sample usage, etc. and auto show these when the user types "pluginalias help".

[czb]

major:
I have already a testing version of it (althought with bugs )
Here it is:
http://dl.getdropbox...4/farr/fsubscript.js
But you must also have the latest fscritp.js which is here:
http://dl.getdropbox...5064/farr/fscript.js

For the plugin you want to have html settings for, just add settings:absolute path pointing to the settings.html (similarly it is done with icon etc)

then go to fssc and you should see settings option next to your plugin. Give it a test

Minor:
There are already some variables. We may discuss adding others, but I am not very much fond of filling in many things Help is a good idea. We could add help:"absolute path" to objects and in fssc we could add new link to help. What do you think?

[ewemoa]

I noticed:

  http://github.com/cz...ubscript/tree/master

and:

  ecaradec started following czb about 20 hours ago

at:

  http://github.com/ecaradec/



mouser and I have some bits we've been working on which we were thinking might be good to merge relatively soon.  It's getting pretty confusing juggling all of the different versions [1]

One of the bits we've been working on is improving onSearchBegin()'s behavior.

Should I just post what I have at the moment or try to merge czb's latest with what I've got and then post the result?  The latter has an advantage in that some of our improvements might only work with an as-yet unreleased FARR.

Ah, and as for a feature request, I have a use for being able to monitor folders for changes (e.g. files have been added or deleted).  I read something about a FileSystemWatcher but I don't really have any idea whether this or some other non-polling method might be usable for FSubScript plugins.  Any clues anyone?


[1] Though in my case being able to run multiple instances of FARR simultaneously has mitigated the difficulties somewhat.

[ewemoa]

Starting off w/ a quote from another thread

To have list of useful functions which make js developers life easier. The problem is to decide which to add on the list

-czb (November 28, 2008, 08:58 AM)

I've been watching some Douglas Crockford videos and reading some things by him and have started to come across some functions that seem nice.

trim() has already been mentioned.

One I thing I think czb could appreciate especially in his code is supplant() combined with factoring out a lot of those HTML and CSS fragments to files   [1]

I think it'd be nice to have these (and perhaps others) but I'm not sure about whether they should be added via prototypes -- doing it that way seems like it would mess w/ global state so perhaps initially they could just be made available via a kind of "fake" namespace.

Perhaps other things from the following would be of interest too:

http://javascript.cr...rd.com/remedial.html


[1] FWIW, I first saw this in the 3rd video (Yahoo! Video | M4V) of the 4-part series at around 12:53.  The idea I was familiar with from Perl and Python and I was missing it in JS.

[ecaradec]

ewemoa, I can try to let git merge your change by importing it in a branch for you and then merge it. May be we should have a special thread to discuss technical decision so that the feature thread does not get filled with git tips... ?
We could have two branches. One that work with the currently released farr and one that work with the not yet released farr.

Ah, and as for a feature request, I have a use for being able to monitor folders for changes

Do you need it for reloading scripts ? or for some other reason ? In the first case FScript could reset the script engine and reload.

I'm done with the GetObject function. It was just what I thought and I will publish it today or tomorrow. This will allow to read the registry and some other uses like navigating network shares...

[ewemoa]

ewemoa, I can try to let git merge your change by importing it in a branch for you and then merge it.

-ecaradec (December 05, 2008, 07:04 AM)

We can try that.  I will attach the attempt that mouser and I have been working on.  Perhaps I should warn you about this version though as I didn't incorporate all of the changes from earlier (e.g. no fsubscript*.js processing).

May be we should have a special thread to discuss technical decision so that the feature thread does not get filled with git tips... ?
We could have two branches. One that work with the currently released farr and one that work with the not yet released farr.

New thread is fine by me.

Two branches are fine by me too.  I am still working on learning about git -- perhaps on the new thread we can collect git-related tips for existing contributers and potential contributers.

Regarding the monitoring of folders:

Do you need it for reloading scripts ? or for some other reason ? In the first case FScript could reset the script engine and reload.

It is the latter case -- I have a plugin that periodically looks at the content of a list of folders.  If this is hard, a pain, or time-consuming to implement, I think it's probably not worth implementing just for the sake of this one plugin.

I'm done with the GetObject function. It was just what I thought and I will publish it today or tomorrow. This will allow to read the registry and some other uses like navigating network shares...

Woohoo!  Fantastic 

[czb]

I thing I think czb could appreciate especially in his code is supplant() combined with factoring out a lot of those HTML and CSS fragments to files   [1]

I think it'd be nice to have these (and perhaps others) but I'm not sure about whether they should be added via prototypes -- doing it that way seems like it would mess w/ global state so perhaps initially they could just be made available via a kind of "fake" namespace.

-ewemoa (December 05, 2008, 05:07 AM)

Hi,
I can not imagine how JSON, trim, supplant would mess? But ok it can be in a namespace. What I would do is to make "extensions" folder in fscript plugin and put there all those essential extensions

To the fsubcript*.js => it is fine. I have changed my mind on that and also recommend to use only fsubscript.js. I just have not changed it in my fscript.js Just make sure you have all those small changes I have made in fscript.js on github (like !pi in setstrvalue, init should be there etc) see http://github.com/czb/fsubscript/network

[ecaradec]

I added support for the getObject (download the last fsubscript version ). Here is my test project that allow to read the registry.
I have some issues with it :
- I don't know how to enable completion without setting alias as a value... and alias is not filtered by the forceResultFilter... and complete with a space after the completion. Any idea welcomed. I have a very weak understanding of how the type value is interpreted by farr, it change a lot a various behavior.
- \ is still not triggering the search. I remount it up to fscript.dll. May be the fix don't work ? I have the v2.34.01 of FARR.

[ewemoa]

I can not imagine how JSON, trim, supplant would mess?

-czb (December 05, 2008, 08:00 AM)

If those things never ever changed and everyone wrote code agreeing on their meaning and assumed that they existed may be it wouldn't be a problem (not sure).  But that "if" doesn't seem like it will be true...May be I am not explaining well (or not even understanding well ).

Just make sure you have all those small changes I have made in fscript.js on github (like !pi in setstrvalue, init should be there etc) see http://github.com/czb/fsubscript/network

Thanks for the tips.

[ewemoa]

I added support for the getObject (download the last fsubscript version ). Here is my test project that allow to read the registry.

-ecaradec (December 05, 2008, 05:40 PM)

I tried it out and succeeded in jumping directly to certain locations in regedit   So it looks like enumeration is working...great!

I have some issues with it :
- I don't know how to enable completion without setting alias as a value... and alias is not filtered by the forceResultFilter... and complete with a space after the completion. Any idea welcomed. I have a very weak understanding of how the type value is interpreted by farr, it change a lot a various behavior.
- \ is still not triggering the search. I remount it up to fscript.dll. May be the fix don't work ? I have the v2.34.01 of FARR.

Do I understand correctly that you wish to be able to do something like:

  reg S<press some key for completion>

result might be:

  reg SAM

What I currently observe for pressing tab after "S" is the first result of the results list being selected (I have "Tab autocompletes" checked in Options -> Program Options -> Settings -> Keyboard Interface). [1]

I have been using entrytype PLUGIN for a recent plugin, but I don't know if that will be at all helpful.  I would also be happy to learn about how the entrytype might influence FARR's behavior

May be mouser has some good ideas about your issues.


[1] General FARR question: doesn't anyone want to be able to "cycle" through completion options?  I don't often end up seeing what I want on the first completion possibility...

[ecaradec]

The original purpose of FSubScript was to enable to write and share plugins more easily. It is good news that people experiment FSubScript versions. However I'm a bit lost in the rapid evolutions and the various versions. I don't know what to merge, what is the context and purpose of changes added.
May be the real purpose of FSubScript is to enable FARR user to write their own small plugins and the fact that there is no official FSubScript version is not an issue ? However I find that the original purpose would still be nice.

Here are possibilities we could change the current state :

I may eventually package an official version. However this would only be useful if we want to share plugins.

I think there is two kind of changes : extension functions and fsubscript behavior change.

Extension functions could be easily packaged as individual files and loaded by fsubscript. Functions like this could be store in individual file of folder and be managed by individual person. Ex : a function like enumRegistryKey could be defined in a fsubscriptExt.js and loaded by fsubscript before all scripts. This function could be used by any subscript. Plugins writer could propose individual extensions package whose purpose would be well identified and thus would be easier to track.

FSubscript behavioral changes could be done a bit the same way by replacing fsubscript default methods, but this is more fragile and I'm not sure it is a good idea. I would not go for it right now.

[ewemoa]

The original purpose of FSubScript was to enable to write and share plugins more easily.

-ecaradec (December 14, 2008, 05:49 AM)

I don't think I'm alone in saying that I still believe this to be a good purpose.

However I'm a bit lost in the rapid evolutions and the various versions. I don't know what to merge, what is the context and purpose of changes added.

The main thing I worked on w/ mouser that I did not explain well (to the best of my memory) is improvement of the behavior of onBeginSearch().  I think (most of) the changes we made came about as a result of working on getting the Keyser plugin (the original FSubScript version) to function properly.  We found that the experimental changes we made to FSubScript for it to handle aliases not prefixed w/ "fssc" originally were insufficient to work correctly in certain scenarios so we tried to see if we could get better behavior by modifying FSubScript's fscript.js (and in the process, IIRC, FARR was brushed up a bit too).  In retrospect, I guess it might have been better if we explicitly posted the problems we found and the changes we made as attempts to address these issues.  I am sorry we didn't do that.

If there are specific things in our version of onBeginSearch() that don't make sense to you, please ask us.  I can try to explain why some code is the way it is, and although I may not succeed at this, mouser is likely to be able to clear up my poor attempts

[ewemoa]

Since the typeof operator appears to be slightly broken, may be we can consider adding the following (typeOf function) in some capacity:

typeOf

The typeof prefix operator returns a string based on the type of its parameter. Unfortunately, it provides the wrong result if the operand is null or an array.

The new typeOf global function is intended to replace the defective typeof operator. It produces the same result as typeof, except that it returns 'null' for null and 'array' for arrays.

It can be implemented in JavaScript:

function typeOf(value) {
    var s = typeof value;
    if (s === 'object') {
        if (value) {
            if (typeof value.length === 'number' &&
                    !(value.propertyIsEnumerable('length')) &&
                    typeof value.splice === 'function') {             
                s = 'array';
            }
        } else {
            s = 'null';
        }
    }
    return s;
}

I found it at:

http://javascript.cr...d.com/recommend.html

[ewemoa]

I miss the x flag and named capture for regular expressions that Perl and Python have.

I noticed that someone has an extended regular expression library for JavaScript:

http://stevenlevithan.com/regex/xregexp/

It appears to have support for both of these things (and the license is MIT)

May be others will find this of some use and perhaps at some point we might consider it for FSubScript.

[ecaradec]

Ewemoa I'm not sure we should add a regex library. Javascript has got one and even if this one is more powerful, most people don't master enough regexes so that it would make a difference (me included ).

However it could make sense as a extension library. If some plugin need it then it could chose to package itself as a fsubscript.js AND a extension.js that would be put in an extensions folder and evaluated in the global script space. That way other plugins could use the library, just tell that they require it to function and code won't be duplicated across many plugins.

There could be a separate maintainer for the library.

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

[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 [Select]

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

[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....ions/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

[ewemoa]

I don't think I understand very well the motivation for wanting manifests for FSubScript plugins.  Would you mind elaborating on this?

I looked briefly at the Chromium-related page.  Does it look to you like their example only uses literal values (e.g. no variables nor functions)?

[czb]

Well I have been thinking of an easy way of getting info from not loaded scripts. Now it is done by trial and error regex match of "description" and "displayName" which might be the best solution after all But definitely it is not a "clean" solution

A separated manifest would be ideal but I doubt it is worth the effort and complications involved in multi file scripts.

The idea with storing info in file description would be nice but it does not work for FAT32 so it is useless...

[ewemoa]

Thanks for the explanation.

I wonder if someone provided a sort of tool for plugins that is run right before compressing for distribution, whether creation of a manifest file (possibly optional) might be a feature it could have.  Plugin writers might appreciate having dcupdate files created/updated in a more automated fashion as well.  Perhaps there are other sorts of things that could be built into such a tool.

May be it would be worth considering a tool such as this at some point in the future and around then the issue of manifest files might be revisited.

[ecaradec]

may be we should put everything in dcupdate file ? It look a bit like a manifest...