avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Saturday April 4, 2020, 8:19 pm
  • Proudly celebrating 15 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - jukla [ switch to compact view ]

Pages: [1]
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).


Both your examples seem to involve narrowing FARR's search to only look for a specific type of file and/or in a specific folder. That's what I meant by filters above (and wanted to snap on/off through hotkeys). So in fact we agree that that'd be a good feature!  :Thmbsup:

But Mouser's Case Two explicitly involved a user having an action, rather than a file of a certain type, in mind. But maybe I'm just getting stuck in the semantics here - maybe he was really thinking of something similar to your examples. In that case we ALL agree.   8)


All my FARR-use so far falls under Case One. I don't even understand when Case Two would apply. Can you give an example of such a case?

(The only thing I can think of would be a case where a user is not sure what exactly he's looking for, thus choosing for example only action "edit image" which then filters the search to only include editable images. But that could be had more directly through a filter for image file types.)

I find that 99% of the target files for my searches are for one of these file type categories (in the order given):
text (txt, pdf, doc ...)
application/script (exe, bat, vbs ...)
image (png, jpg, gif ...)
music (mp3...)

If many other users use of FARR also fall into a few categories like that, then filters of the kind I described above would be ideal.

BTW, It would be interesting with a poll on what kinds of searches FARR-users actually do!

jukla i hope you will stick around for the v2 discussions..
Will do!  :Thmbsup:

[...] and i'm understanding some but not all

He he, I guess I got a bit carried away. If you point out what you find most incomprehensible I'll try to clarify (I might also just worsen things though!  :D

I combined three ideas - filters, actions and the L shaped Hotkey help in the GUI - but I guess they could be used separately (or combined with some other solutions) too.

The more I think about it (not that much but anyway...), the more convinced I become that something like the idea of the the L shaped hotkey help would solve a major problem with many small applications: users forgetting what all the hotkeys are and what they do.

Thanks for the welcoming!  :) And for refs to FARR v2 threads. I guess I mostly rehashed thoughts already discussed.  :-[ Anyway, browsing through the threads on actions and filters stimulated me (well that and the fact that I immediately liked FARR's simplicity a whole lot) to elaborate my suggestion a bit more. So here's req 3 & 4 revisited.

My aim was a solution for users that only need 1-3 special filters and (mostly) 1-3 special actions for each file category.

STRUCTURE & SETTINGS -------------------
Shift, Ctrl & Alt are MODKEYS (not changeable)

On some settings page, let users set
- CATEGORIES = files/folders grouped through some property (basic: file extension(s), max/min size, older/newer than date x, folder. Advanced: combos of properties, arrays of (different) combos ...)
- 1-3 FILTERS (defined via categories)
- ACTIONS = copy path; kill; edit; do checksum ...

- Let users tie each FILTER to a MODKEY
- Let users tie 1-3 ACTIONS to each CATEGORY (advanced: even more actions)

- For alternative 1 (below): also tie MODKEY 1-3 to ACTION 1-3 for each CATEGORY

(Presets/templates would simplify all these settings of course.)

OPERATION -------------------

When focus is on search field
[input]      >>> [result]         
type text      >>> do default search
enter/F2/F3...   >>> do default action on result1/2/3...                 
tab/arrow down   >>> stop search & focus result1      

hold modkey1/2/3 (during/after type)  >>> run filtered search 1/2/3                             
release modkey                             >>> snap back and do default search           
modkey + tab/arrow down                 >>>  stop search & focus result1                     

When focus is on results list
[input]      >>> [result]         
release modkey   >>> DO NOT snap back to default search (only snap back when search field has focus)

arrows up/down    >>> navigate list
enter/F2/F3...   >>> default action on result1/2/3...

Alternative 1:
hold modkey1/2/3 + enter       >>> Action1/2/3 on selected
press+release modkey1/2/3    >>> Action1/2/3 on selected
hold modkey1/2/3 + F2/F3...   >>> Action1/2/3 on result2/3...

Alternative 2:
press CTRL + enter       >>> context menu list with Action1/2/3 and more as options
arrows up/down       >>> navigate list
release CTRL or enter again    >>> do action selected in list
(Advanced: instead of list, use 3x3 cell matrix. Hold up & right to  select upper right cell. And so on.)

To help remember filters & actions and their modkeys, add three small boxes forming an L shape somewhere in the GUI. The tags on the boxes describes available modkey filters/actions and correspond to the relative placement of the shift, ctrl and alt keys on standard keyboards. When holding a modkey, its box is colored/highlighted.

Great program!!!    :Thmbsup:


1. Let mousewheel = scroll hits list up/down edit2 even when search field has focus

2. Tweaks for page up/down & home/end buttons:
- a. when focus in search field, "page down" = one page down in results.
- b. when focus in search field, "end" = to end of results.
- c. when focus in results, "page up"/"home" should work as now BUT when getting to topmost result item, let NEXT "page up"/"home" keypress jump to "search field"  edit: ok, just noticed that TAB jumps between search/results so 2c could be scrapped.

3. Add content filters. Let user specify groups of file name filters (for example TXT = .txt, .doc etc) and apply filter modes via hotkeys, for example ALT, CTRL and SHIFT. When focus in search field, let default mode "snap back" after hotkey release. After moving focus to results, keep filter on. Also, add noticeable interface change to signal current mode (change main title bar color, text and/or color dot in task bar etc)

4. Add action modifiers. Let user specify what action to do when pressing Enter + modifier (CTRL/SHIFT/ALT/WIN). Many of the context menu actions could be used (copy path, explore here...)
As above, add noticeable interface change to signal current mode.

5. When in auto resize mode AND having horizontal scroll bar, the last hit in the list (for example hit 5 out of 5) is partly covered by the scroll bar.

6. Add minimize/maximize buttons.

7. Let two taps on CTRL launch/exit FARR

edit2 ok, two more:
8. Add options for more minimal interface: no column header row, no title bar, smaller scrollbars

9. Disallow executing results on ALT + F-key (for example, ALT+F4)

Pages: [1]