Live filter - typing speed v when filter is executed

[petersboulton]

The new 'Live filter' feature is brilliant.

However, I get the impression that it applies the filter immediately, after each keystroke. On a relatively small folder this is fine but on large folders there can be quite a noticeable delay after each keystroke.

I think the search should only be executed (=filter implemented) a certain number of milliseconds after the last keystroke. That would make the feature seem more responsive.

In other words, say the delay interval is 300ms. As long as the interval between key presses is faster than this, the search (filter) does not get applied. If the interval since the last keystroke in the live filter box > 300ms then the search (filter) runs.

I think this would make the feature more responsive.

Thanks!

[highend]

v16.90.0313 - 2016-06-24 16:59
* Live Filter Box: Experimentally removed the 500 msecs delay
unconditionally. So you get instant results now.

[petersboulton]

v16.90.0313 - 2016-06-24 16:59
* Live Filter Box: Experimentally removed the 500 msecs delay
unconditionally. So you get instant results now.

Great... so can it please be put back in then?

Accepted that no delay works best on small folders and delay works best on large folders.

Surely it would not be impossible to use a logic like "if folder content > n files then delay=300ms else delay=0ms"? If these properties could be exposed in the Settings we could all be happy.

[kinook]

+1.

The same option/behavior should also take effect when typing in the list to select a file (without the live filter). Especially on network drives, updating on each keystroke when typing several letters quickly is painfully slow.

[petersboulton]

+1.

The same option/behavior should also take effect when typing in the list to select a file (without the live filter). Especially on network drives, updating on each keystroke when typing several letters quickly is painfully slow.

+1 on yours! In the scenario you describe you currently have to type quite fast on a shorter list to actually get the several letters you want to work.

As in, I type (quickly) 'g', 'a' and then I hesitate before typing the 'r' and it jumps from 'ga*' to 'r*'. The 'delay and search' logic would get round this issue too.

[admin]

The same option/behavior should also take effect when typing in the list to select a file (without the live filter). Especially on network drives, updating on each keystroke when typing several letters quickly is painfully slow.

You mean Type Ahead Find? The list is not updated on TAF, just scrolled.

[kinook]

Yep, just scrolling can be very slow (several second delay with each char typed). This would be improved by delaying processing while typing, ala Explorer (delay would occur only once after multiple letters typed and scroll position / selection would apply to all the typed chars).

[admin]

Slow scrolling can only be caused by retrieving icons. You will probably benefit from ticking these:

Configuration | Refresh, Icons, History | Icons | Use generic icons for super-fast browsing
Configuration | Refresh, Icons, History | Icons | But only in network locations

[kinook]

I didn't have those checked, but checking them didn't help.

The delay appears to be related to displaying a Custom: Version column, with List trigger.

[admin]

The delay appears to be related to displaying a Custom: Version column, with List trigger.

Sure, that one can really take time in a network.

I'll make a mental note on adding a typing delay here...

[admin]

Next version you can tweak the delay for the LFB.

[TheQwerty]

Tip: For anyone using custom script columns, you may want to consider adding detection of live filtering and an early abort to your script.

Code: Select all

if (Get('FocusedControl') LikeI 'LFB') { return 'live filter in use'; }

This will favor more responsive live-filtering without needing to remove the column, but will require a Refresh or Refresh Column to retrieve the values when filtering is complete.

Keep in mind that Property/Special Property columns which may be slow can also be converted to script columns to make use of this early-return:

Code: Select all

if (Get('FocusedControl') LikeI 'LFB') { return 'live filter in use'; }
return Property('#hash.md5', <cc_item>);

It is not the ideal solution but given limitations of the current design might be the best we can achieve.