DonationCoder.com Software > Find And Run Robot

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

<< < (13/16) > >>

jdmarch:
Just to be clear: both the running task and the file would appear on the selection list. The running task would appear first, so pressing Enter would switch to it, but if the user wanted to launch a new instance (for programs which permit this), she could select and launch the file instead of the task.

I agree, there would be no reason not to support a SWITCH verb, which would be one of the wonderful universe of search modifier verbs, this one restricted only to running tasks.

jdmarch:
While multiple verbs are not a top priority for me, I do think that they could eventually be very useful.

The number and function of entry fields, as well as the contents of the drop-down selection list, would vary depending on the preceding verbs or objects selected. So I agree with the proposal for an initial FIND verb followed by an arbitrary object, followed by an object-dependent secondary verb.
For example:
  FIND <taskname> KILL
  FIND <taskname> SWITCH
  FIND <file name> DELETE
  FIND <tunename> ENQUEUE

The first of these could be entered as
  <BREAK>
  <ESCAPE>
  F
  <ENTER> (or TAB #, or TAB arrow arrow arrow ENTER, etc, just as now)
  taskname
  K
  <ENTER>

This would also be useful after search modifier verbs, which restrict the object selection list, which in turn restricts the secondary verb selection list:
  MP3 <tunename> ENQUEUE
  TASK <taskname> KILL

Amadawn:
If the main problem shown by this thread is how to distinguish between the "main case" where FARR must do a regular search and the "5%" case, in which we must provide FARR with a "verb" (or command), why can't you just select a "escape character" that must be used for commands?

For instance, maybe we could use ">" which is not allowed in any Windows filename. If ">" is the first character on the command line, assume that it is followed by a command (like "define", for instance). Otherwise, assume that we are in "normal" mode.

Of course, while in normal mode, you could still be able to stack "commands" as it has been discussed above (QuickSilver style).

Does this make sense?

Amadawn

jdmarch:
Amadawn, the keystroke count of your suggestion is the same as mine (both require pressing an escape key to move from launch-only mode to multiple-verb-choice mode, although actually ">" requires holding down the shift key).

But to me, the multiple-field model is more friendly, especially to newbies, than the single-command-line model.

First, the use of any special-purpose characters (e.g.">" here, or "|" in the results field of the group edit dialog) makes a command line look forbidding and potentially confusing.

Second, the visible presence of a default OPEN/LAUNCH/RUN verb, in the first entry field, provides a visual clue that other verbs are possible. And the number of available entry fields gives a clue as to the desired syntax (e.g. after OPEN, there is just one more visible field, but after FIND, there are at least 2 more visible fields, the exact number depending on subsequent choices). So, at least in theory, this model holds the hand of the inexperienced user without inconveniencing the experienced user.

I expect that most of us having this conversation are very comfortable with multi-part command lines, but I'm trying to think what would work better for others. Maybe I'm wrong about this: it would take some usability testing with inexperienced users to be sure.

jgpaiva:
jdmarch:
I think that the possible ambiguities in the Farr engine, can only come from the way we define the aliases.
I mean, using the great stack-pile method that Jan-S proposed, i think that Farr only has to do what he does now.
The only difference is that when we select something, it's name gets replaced by it's full path.
The only hard thing is define the aliases, but even that, i don't consider very hard. I've seen that there is much people that are "experts" in aliases, and others willing to learn (like myself ;) )

Another thing you mentioned is selecting with SPACE. I think this has been referenced before, and can't be done, since one of the most asked-for feature was "f f" finding firefox. (i myself would like to select with space too, maybe it could be an option?)

I love the way you said that the switch tasks- function could work, and i think it's perfect. And it even doesn't need to have the option to disable it, if Farr will have the adaptive scoring like it is predicted will have, if you usually don't use the "switch to" option, it won't come first, and ENTER will just open a new instance.

Mouser's "search modifiers", that's a great idea! it has happened too many times to have another option come after the one i wanted, when working on something!

As for the two field-arrangement, i don't agree with you, i think that having a command line to type exactly what you want is more natural, i mean, everything goes in the same place. I understand that it is to have distinction between entering an action or a file, but IMO, it generates some confusion. I think that having the letters change colour when you type an actions would be easier. (I also think this should be features in the stack-bar, to have some idea of what we're doing.)

Amadawn:
My opinion is that is the aliases (or actions, or whatever you call it ;) ) are configurable, you can change their names, and you can include that character in their names. I don't think there is a need to force the character to be there, unless it helps Farr to identify what it is working on, or something like that.

Navigation

[0] Message Index

[#] Next page

[*] Previous page