DonationCoder.com Software > Find And Run Robot

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

(1/3) > >>

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 > [email protected]
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:


* https://www.donationcoder.com/forum/index.php?topic=2277.0
* https://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.
--- End quote ---
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.
--- End quote ---
Doesn't the shortcut key solve that ?

Navigation

[0] Message Index

[#] Next page