DonationCoder.com Software > Find And Run Robot

FARR version 2 - discuss the best way to handle 'actions'

<< < (7/16) > >>

jgpaiva:
I was thinking abou this, and i got to the conclusion that we might be over-complicating this problem.
The thing is that having farr parse a string in a way that makes sense is too dificult. And the 2 boxes- idea, just adds to the problem, as it becomes more and more dificult.

I have an inovative idea ;)
How about instead of having poor farr trying to parse a string based on a lot of criteria, not have those rulles defined in each of the alias itself?
i.e. The alias would have the rules for what could come before or after it.
Right now, it is possible to do this, an alias with this regex:
(.txt) edit(.*)
with this line of execution,
c:\programas\pspad\pspad.exe $$1 $$2 |pspad $$1 $$2
Is close to execute what i'm referring to.

My idea is:
How about if initially, farr displayed every file and alias (the alias has to not need arguments before it) started by the letters you type.
Then, when you find the alias or the file you want, you press enter to launch it, or space to start another search based on your previous selection. Which means that if your first selection was a ".txt" file, "edit" alias could appear in the next option. If it was a .exe file, "edit" wouldn't have any sense, so, it doesn't appear.
What i mean is, have farr select a result on space, and the next results are based on that result.

This solution creates only 2 problems with prior requests:
1) The "f f" request, which would select firefox with the type of "f f", for which i can't find a solution other than typing "f*f".
2) The command line parameters solution, that i think can be fixed by adding a comma.I.E., "mini, capture" would make minicap capture the screen (if capture was the command line parameter that would acomplish that).

 :feedback: :feedback:

mouser:
one problem with this is as you say, it makes it impossible to use spaces in the search.  so you cant use multiple words to narrow down a search, which was one of the most requested features for version 2..

jgpaiva:
I just found out that the regex example i posted above doesn't work as i thought it would. I hope that you understand what i mean. *sorry*

Jan-S:
What about nested commands in this two-box solution (see jgpaiva's post above)? I think they would be great, especially as they would nicely match the ideas of being able to add buttons and submenus to FARR to use it as a launch bar, too (submenus = nested aliases).
I think a single edit box would be better, and I also think you should be able to specify the command first OR search for the file first.
When you start typing, FARR just matches the string against all keywords (aliases, commands) and all files - the commands should have a special icon (user-definable) or maybe even some special text attribute (bold, underlined, colored). They should not have to begin with a special character (like *), but of course you can create your commands like that if you like it.
Pressing RETURN launches the first entry - no matter if it is a file or a command. Pressing a number key also immediately launches the specified entry.
Pressing TAB+TAB uses the first file, meaning you are then presented a list of possible actions. If you want to take another file and execute a special command on it, it should be possible to select it using the arrow keys and press TAB, or, which would be much faster, press TAB, followed by the number (I think it's important not to be forced to use the arrow keys).
FARR would have to display the current command / params stack (as suggested, but a textual representation should be enough), marking the position that needs to be filled next.

To execute jgpaiva's example 'mp3 enqueue somemusic.mp3' the following sequences would be possible:
"mp3" -> FARR recognizes the keyword and shows the 'mp3' command in the list, continuing to scan for files matching "mp3" nevertheless
TAB -> FARR adds 'mp3' to the command stack, empties the edit box and displays something like "mp3 > [?]" in the status bar; the list is populated with mp3's subcommands
"enq" TAB (or press #) -> Assuming that 'enqueue' was the first match for "enq", FARR adds 'enqueue' to the command stack, empties the edit box and displays "mp3 > enqueue > [?]" in the status bar; the list is populated with the last used files
"some" -> FARR lists all files that match "some" (BTW it could even list all matching directories or keywords that modify the search path)
# -> FARR adds the specified file to the command stack, finds that no additional params are needed and executed the command

Another sequence:
"some mp3" -> FARR lists all files that match "some mp3" (e.g. this could mean *some*mp3*)
TAB -> FARR switches focus to the list and shows that it is awaiting a file to be used with a command, e.g. displaying "? > [?]"
# -> FARR adds the specified file to the command stack (on the second position), restores focus to the edit box and clears it, displaying "[?] > somemusic.mp3". The list is populated with available commands that take a file as one of their params - this is transitive, e.g. 'mp3' is listed because it offers subcommands that accept a file param (or maybe 'mp3 > play' and 'mp3 > enqueue' should be listed immediately?)
"mp" -> FARR limits the list to all fitting commands that also match "mp"
# / Return / Space / TAB -> FARR takes the specified cmd / first cmd / first cmd / switches focus to list, adds 'mp3' to the command stack (first position), finds that 'mp3' is not satisfied with just a file param and thus clears the edit box (restoring focus to it), displaying "mp3 > [?] > somemusic.mp3", populating the list with all commands in the 'mp3' menu that accept a file param
"enq" & RETURN / # -> inserts 'enqueue' into the middle command stack position, finds that the command is complete and executes it

I think this is better because you can start typing rightaway what you have on your mind, not taking care of which box you are in. Also this approach would allow for commands accepting multiple params (e.g. two files or a file and a folder). It would be perfect if you could access submenus without having to press TAB, e.g. "mp3"-TAB-"enq" should equal to "mp3 enq" - when generally listing these commands in the format "mp3 > enqueue", "mp3 > play", "mp3 > mute", "inet > apache > start" etc. this should be possible without special treatment of commands.

jgpaiva:
Mouser, how about using the prosition i posted, but instead of using space to accept the result, use tab, and space to narrow searches?
(the solution you posted has the same problem, if you type the action before you type the file on that action is to be executed, doesn't it?)

Navigation

[0] Message Index

[#] Next page

[*] Previous page