Little things missing to build "object > action" style command line in FARR

[ecaradec]

I did try to build something like object > action > ... for farr. Here is for example what the farr command line would look like.
a) 'sdfsdfsdf' > mailto > toto@tutu.com
b) 'sfsdffs' > appendto > c:\test.txt
c) c:\A.bat; c:\B.txt; c:\C.txt > zipto > c:\f.zip

Very little things miss for building that in FARR. I don't know if there is interest for this kind of presentation.
- First is the ability to call a dosearch from a plugin. That way the plugin could filter the command line and start a search from a part of the query. setsearch and setsearchnogo clear the current query so they can't be used for doing that.
- Second is FARR completion that by default clear all the current query. Its possible to build line like the (c) but after your first result you must absolutely not hit tab because it would clear the query. One way I see to do that is to allow the plugin to set a completion prefix that would be added to the completion : If I type c:\A.bat; c:\B.txt; <dosearch +files> then the plugin would set "c:\A.bat; c:\B.txt;" as the prefix so that tab add this to the completion line.
Another way would be for farr to call back the plugin to ask him if it want to handle completion but it certainly would complexify the system.

I did prototype it, and it work as long as I handle all the case. This two points would allow to make this kind of selection to cooperate with other plugins.

Cheers

Manu

[mouser]

We've had some very long running discussions about building multi-part actions in FARR:

• http://www.donationcoder.com/forum/index.php?topic=2277.0
• http://www.donationcoder.com/forum/index.php?topic=3713.0

usually what happens is that i end up feeling like i dont have a perfect grasp on the "right" way to add it in terms of user interface, and so end up putting off implementing it.

but i'm open to the possibility of figuring out a "pretty good" solution that handles most cases..

the basic idea of having a key/character which is a separator between items, as you say like > or ; in your examples (though those could be used in other cases so we probably need another character), and then have FARR always be searching using the rightmost item, and then try to combine them.  That sounds like it might handle most of these cases..  and then the icing on the cake would be if we had the custom context menu actions as we've discussed elsewhere and let that be triggered by the separator as well..

[ecaradec]

usually what happens is that i end up feeling like i dont have a perfect grasp on the "right" way to add it in terms of user interface, and so end up putting off implementing it.

Yes, FARR mainly work with free form text and the difficult part came from that. Quicksilver UI is breaking the request in parts this make the comprehension easier for the software. I did like how FARR work anyways. Plain text is easier to copy and paste.
I read about half of the post from the two threads, I think that my idea is a bit different. I did use > as a separator, but I would give up the decision of that to the plugins.
The idea is use the plugin to emit alias that the user can use for autocompleting the request. Suppose I would like to make a plugin that would zip a list of files. The complete request would look something like : file1, file2, file3 > zipto > file.zip.
Here is how it could work :
I type 'fil', FARR propose me file1, file2, file3.
Hit TAB, FARR propose me file1(current result ), group and zip(more on zip later ). group can't be selected but can be autocomplete.
Hit TAB on group, FARR complete to "file,".
The plugin can decide that "file," is a pattern requiring to select more files and run a dosearch command to enable selecting some kind of file.
If its not enough discrimining, the group plugin could decide to autocomplete to [file], or %%file%%. There might be several kind of group available like group_with_comma, or group_with_comma_and_parenthesis. The issue here is that plugins may or may not recognize some kind of group pattern but I think a simple one with comma and a more complex but more discriminating should be enough for all uses. The simpler is better for deleting last selection with ctrl-tab ihmo.
Ok now you have file1, file2, file3 on your command line. group and zip option are available.
TAB on zip: now you have file1, file2, file3 > zip >
This pattern start a dosearch for the target file.
It could seem like a lot of work but the dosearch could actually handle most of the work. A group plugin will handle the first part, a zip plugin will use the group of file and a target search is a normal dosearch with modifier for selecting file only.
Everything could work only by notation convention. FARR need to start dosearch when asked and a way to complete that does not clear the command line. Does it make sense ? Could that work ?

Manu

[mouser]

what if we instead had a key that one would use to QUEUE up the current result.
so whether you typed a file or a command, you could either launch it as normal, or "queue" it by hitting alt+Q or something like that (or control+#).  The queued items would have to be shown somewhere, not sure where.

after an item is queued, the search box clears and you can type in new stuff to search for.  FARR would restrict results to items that can work with the already queued thing(s).

so if you queue a file, only alias commands that work with files or other files would be matched/
and if you queue a command, no more alias commands would be matched, only files.

issues to be solved:
how to show queued list of items
how to let user edit/clear it.
how to have user indicate that they want to queue a result rather than launch it.

ideally the queuing system could be used to also implement custom plugin actions (ie a process plugin could let you select a process and then "queue" it and then select from a plugin-specific set of actions to apply to it).

[ecaradec]

I tried to make a sample plugin that could recognize pattern and use the autocompletion in the way I describe before. I'm now convince that it can't work.
I really like the idea of a different shortcut to queue items.
Here is an idea on how to show the queue list. May be a user could just move the cursor to the item he want to change with the cursor key and FARR could activate that part of the query ?

how to have user indicate that they want to queue a result rather than launch it.

Doesn't the shortcut key solve that ?

[mouser]

i wonder how people would react in general if we made it always the case that when you hit alt+# or enter, it didn't launch right away by default, but always just "selected" or "queued" the item triggered and then presented options like:
1) LAUNCH
2) QUEUE
3) ... context sensitive stuff here.

using a special hotkey would work too and leave enter to do the launch.. or we could make it an option i suppose.

[ecaradec]

It does not sound very fast to ask each time whether to launch or to queue ? . I think I would personnaly prefer a shortcut-key.

Manu

[nitrix-ud]

It does not sound very fast to ask each time whether to launch or to queue ?

agreed, the default behavior should not change, FARR is the fastest and should remain the fastest 

i suggest shift+enter to queue an item, which is an often seen hotkey (multimedia player...)
i also suggest that one could select multiple items !!!

[mouser]

it would only be 1 extra press of enter, but ok fair enough.. it would be easy to make it an option, so if user still wants alt+# and enter to launch, they would use ctrl+# or ctrl+enter to queue.

[nitrix-ud]

it would only be 1 extra press of enter, but ok fair enough..

yes but still ...
it changes the feeling...
i personnaly never use alt+# or ctrl+#

i usually search/type until the result i want is first
otherwise i use the arrows to select the second or third result...

i don't think many people use alt+# or ctrl+#, i already suggested to use alt and ctrl to modify the enter behavior...
ex : alt+enter, launch selected result and STAYOPEN
shift+enter, to queue the selected result
ctrl+enter, to open the shell context menu
etc...

and when the time comes that one will be able to select multiple items... this will still works !

that would be very usefull

cheers, nitrix

[jgpaiva]

I'll just throw a bunch of ideas:

I love both the idea of having shift+enter or alt+q. BUT, shift+enter is already used in winamp for queueing (for exaple) and i think makes more sense.
About de-queing, with alt+q it'd be easier, shift+alt+q could be used.
Another option would be ctrl+tab/ctrl+shift+tab.

Alt + # / ctrl + # would have a big advantage: one would be able to have a "queue and don't clear" action for alt+shift+#/ctrl + shift + #, which would allow us to queue several items with one search.


Now,my conclusions:
Best system:

• shift + enter to queue and clear textbox,
• shift + ctrl + enter to queue and don't clear the textbox
• backspace when the textbox is cleared deletes items from the queue
• represent the queue as a simple filename + filename + filename ... line above the textbox.

[ecaradec]

I don't use alt+# either. ctrl+enter or shift+enter seem like the most logical to push items on the queue. It mean go to line without validation in several applications. I vote for it .

represent the queue as a simple filename + filename + filename ... line above the textbox.

That would be good enough at frst. I'm not sure that editing items in the queue would be useful anyways.