Messages - jukla [ switch to compact view ]

Pages: [1] 2next
This is a very handy script!  :)

Here are two additions I found useful. Add them if you like them.

1. Add box for typing or pasting a path from clipboard when browsing for root folder:

2. When starting the program, populate the ListView with the folder delempty.exe resides in and all its subfolders.

Gosub, COUNT

Here's a request:
When selecting multiple rows in the listview, allow to toggle check/uncheck checkbox for all of them with space (currently only one row gets checked/unchecked). I don't know how to implement that in AutoHotKey myself, but I bet it can be done.

we could also say that whenever an exact match to an action is typed, it is automatically recognized as an action; just keep in mind that searching for file result would get disrupted while you were typing.
Maybe I misinterpret you here, but wouldn't that cause the problematic ambiguity for FARR that the modifier prefix is supposed to solve?

I might type "dylan play" in search of the file "dylan play.doc" (a script to a play about Bob Dylan, let us say) but can't find it since "play" is interpreted as action modifier and there are too many other files matching "dylan"...

Worst case scenario: a user wants to search for "kill'em all" by Metallica but FARR ends all running processes! ;-)

I think when you highlighted a file and start typing, FARR should put the filename into the list (just the filename, without path - this means FARR has to map the abbreviated form to the full file name, internally (maybe it should even just keep the part of the filename you entered)) and append a space sign, the command prefix character and the first character you typed, filling the result list with matching actions.
-Jan-S (building on QuickBrownFox)
Good solution!
How about going with your last option (= just keep the entered part of the filename in the search box) and in addition reserve the first line in the results box for the full title?

the most important part of this idea is that the special key comes as a PREFIX to an action/modifier


But is the combination of "initial space prefix" plus some other suffix/prefix for multiple modifiers out of the question? Just try to type " mp3" and compare it to "+mp3". The former is a lot quicker (due to space bar size and position). Come to think of it, the most coherent way to have the "initial space prefix" might be to just make it an (optional) addition on top of another prefix.

Example: " mp3 +edit +d: moby" would (i) search for mp3-files, (ii) set action to edit, (iii) narrow search to D: and look for files with "moby" in name.

Those who don't like the "initial space prefix" could still type "+mp3 +edit +d: moby"

Another quick "extra prefix" would be to read all phrases that begin with an uppercase letter as modifiers ("Kill" is a modifier, "kill" is not).

re: actions and modifiers:
1 & 2! Also, since most modifier phrases will be brief (mp3, edit, kill...), allow multiple columns in the result list (edit: only for the list of actions, not for regular results). That gives maximum overview of available actions and speeds up selection.

jgpaiva (on hotkeys):

hotkeys are counter-intuitive, someone that uses the program for the first time, doesn't know them.
Often true, but not if the hotkeys are few and simple and help is displayed in the GUI. Like pressing CTRL in Photoshop and seeing the title of the special action in the taskbar.

hotkeys aren't dynamic, you have to set them up
Yes, but there could be helpful templates. And some default hotkeys (narrow search to text, to music etc) that'd work for many persons.

hotkeys are limited, which means that you'd only have a bunch of actions
True, but how often are more than "a bunch" of actions for a file type needed? If seldom, then falling back on context menu in those cases would be more efficient than alternative solutions, since users might forget a seldomly used action's name in FARR and/or spelling (but recognize it when seeing it in a context menu).

lots of people have several hotkeys set in their system, that might conflict.
True, but the risk is small if the hotkeys are limited to one-key-hotkeys like CTRL, SHIFT or ALT since no app makes (or should ever make) a single press of CTRL etc into a GLOBAL hotkey.

jgpaiva (later post):
As for hotkeys, modifier hotkeys might have one problem: they already exist right now, ctrl, alt and ctrl+alt are already used for different launch methods for farr.
True. That could be changed, but I admit that it's a drawback.

Ok, I'll rest my hotkey craze now.  :-[

Regarding a modifier prefix: File names never begin with a space, right? If so, then a space at the start of the search box could work as prefix. FARR could read anything that matches [initial space + string of letters without space + space] as a modifier.

Example: " mp3 moby" would search mp3-files with string "moby" in name

That's perhaps quicker than using some other prefix, especially some unusual key.

Drawback1: might collide with some other use of the space bar in FARR?

drawback2: only supports one modifier.

But multiple modifiers COULD be handled by a suffix (though that would complicate things) at the end of a string of multiple space separated modifiers.

Example: " vbs edit# xmltv" would search vbs-files (=VBscript) in folder NNN with string "xmltv" in name and set default action to edit

Another alternative would be a special letter between each extra modifier.
Example: "+" in " vbs+edit xmltv"


Ok, I see the problem now.

"and let users have two keyboards so they can type in both at the same time and restrict results in both windows."

Let them have four hands too  ;D

One could perhaps handle the problem with FARR interpreting misspelled action modifiers as regular search terms by demanding some unusual prefix letter before all actions. Alternatively, when pressing some hotkey, FARR interprets the next term as an ACTION specification (and highlights the term to show that the hotkey worked)
A downside is that users must press an extra letter/hotkey.

With risk of repetition, another solution is to sidestep the problem more generally by letting users specify actions and/or filters for file-types or certain folders through hotkeys alone. (Yep, I'm turning more and more into a hotkey fanatic)

- Hotkeys have less ambiguities - either you press the right one or you don't.
- When known, hotkeys are faster than typing.

- Users may fail to memorize them, making them slower AND frustrating.

But that can be handled by some hotkey help displayed in the GUI, like the L i illustrated or like how Adobe Photoshop shows alternative actions in the taskbar when for example CTRL is held down.

- There's tension between uncomplicated hotkeys and having many alternative actions/filters to choose from. Handling the latter through hotkeys necessitates more complexity. Which take more time and more effort to remember.

But I think a good trade-off would be to
(1) to (as said before) guide the hotkeys through help in the GUI and
(2) limit them to one- or two-key-combos. For example: simple hotkeys = one of CTRL/ALT/SHIFT. More complex hotkeys = simple hotkey + another key (perhaps right SHIFT can be used for that?). That give's six modes in addition to default. Wouldn't that cover most usage for most users?  :tellme: The rest could be handled via context menu.

Also, if the hotkeys are given different usage for when the search field is in focus (call them search modifying hotkeys) and results list is in focus (call them action specifying hotkeys) we get six file/folder filter modes and six action modes from only four keys (in addition to the default modes).

Pages: [1] 2next
Go to full version