146
FARR Plugins and Aliases / Re: Post your FARR v2 Plugin Idea Requests Here - Plugin Writers Read In
« on: June 21, 2007, 12:39 PM »Good idea to allow any application to act a plugin.. I'd very much find that helpful because AutoHotkey can't compile into DLLs! So I can't return any informatino to FARR like you said. I'm not sure if to use the +keyword for this would be the best implementation though.
An alternative way of doing this:
* Someone would make a simple EXE output/stdout wrapper as a plugin (dll).
We would then just be able to create quick scripts that would integrate with farr without any extra work, using the current alias system. I'd pay some credits for a solution to this idea.-justice (June 01, 2007, 05:32 AM)
This has got me thinking about ways to make alias creation even easier. Regexes are overkill for all but the few where the expression has no unique prefix.for For the rest a simpler syntax should make it easier for a user to create an alias on the fly for any new command they encounter. I've been thinking for some time that an alias should be selected in the same way as a folder - you shouldn't need to type in the whole name to activate it. That would mean that you could not just paste an alias and its parameters directly into Farr's search window and have it run, but it does allow greater flexibility in other directions.
Here's a schema for an alternative .alias format (+ indicates an optional item, * an optional repeated item):
ALIASES
*ITEM
+NAME
RESULT
*PARAMETER
ACTION (none/enter/find/do)
+ARGUMENT
+HISTORY (open/closed, search/nosearch)
*ITEM
Recursive, yes - but so is a file system. Names are selected in the same way as folder names, recursively searching through searchable history. RESULT is a single command string, with placemarkers for any parameters needed. ACTION is the method to produce a particular parameter. If there is a history attached to the parameter, the list there is displayed first so that a previously entered string can be reused. If the history is open and a new string is chosen, then it is added to the list. Such a new parameter can be given a NAME by which it is found, and may take parameters of its own, whose ACTION and HISTORY behaviour can specified.
ACTION none restricts choice to the parameters in the exsisting history list
ACTION enter allows the user to type in a string. The optional argument is a prompt
ACTION find is a recursive call to Farr, returning the string that would have been launched (e.g. a filename) as a parameter. The argument is a search string.
ACTION do The argument launches an external program that returns a string (representing perhaps an open window, an active task, or a registry key)
Example:
NAME cmd
RESULT c:\windows\nircmd.exe ...
PARAMETER
ACTION enter ( complete the rest of the command string)
HISTORY closed search ( allow new items, and find them with out having to select cmd first)
ITEM
RESULT screensaver
ITEM
RESULT monitor ... ( this needs another parameter)
PARAMETER
ACTION none ( allow only the supplied parameters)
HISTORY closed nosearch
ITEM
RESULT on
ITEM
RESULT off
ITEM
RESULT low
ITEM
NAME Resolution
RESULT setdisplay ...
HISTORY open nosearch ( collect valid settings)
ITEM
RESULT 800 600 16
and so on...