XYplorer Beta Club

@klownboy: The ESC idea is not bad. But I'm not totally convinced. Need more time to play with it, and more feedback from others.

autocart wrote:1) The filtering process is "relatively" slow (but if that was all it would be ok, and to be fair, I did not compare it to other filtering operations)

2) The live filtering seems to filter the list after each typed letter (I know, this is probably not a bug since it is the meaning of "live" filter, but for the sake of typing whole words at once, maybe it could wait for a split of a second to see if another letter is typed before starting the filtering)

3) A lot of times it happens that the first "t" of the word "test" will be displayed in the LFB but the caret does not move to the right immediately. Instead it starts filtering but still accepts user input in the LFB. This results in a display of "estt" in the LFB (instead of "test") and in a live filter of "t" (as shown in the live filter info bar).
(Also, if a live filter of "t" has run successfully and is therefore active, and I then type "est", it may result in a live filter of "te" instead of "test".)

4) Depending on when I hit Esc to interrupt the filtering process, it can happen that the LFB is empty but the live filter info bar still is visible and displays something. If I then right click on it and pick "Remove Live Filter" it runs one of the recently used terms for the live filter instead of removing it. (No. 4 seems to be ok in a fresh version. Seems, I have to keep observing this behaviour to return a better report but No. 1-3 are unaffected by this.)

Conclusion:
I assume that the ovserved bug(s) are due to a slow intranet connection.

admin wrote:

Code: Select all

v17.60.0103 - 2017-03-01 19:42
...
    + Configuration | Filters & Type Ahead Find | Live Filter Box: Added a field
      enter the "Delay before filter is applied (in milliseconds)".
      The tweak "LiveFilterDelay" is hereby raised to GUI.
      Factory default is 0 (to show off some speed) but I'm personally happy
      with 300 ms. Reduces the browsing action if you type faster than 300 ms
      between the strokes.

I was not aware of that tweak but now that it is raised to GUI and I became aware of it, setting that value to e.g. 300 it solves numbers 2 and 3, thx. Number 1 is partly solved. If the listing is not a huge branch view or if it finds only a few items (which is the case more often now bc of LiveFilterDelay), then it is probably fast.

Regarding number 4 again and other (new?) problems when hitting Esc during the filtering process:

admin wrote:This e.g. is a clear bug to me:
" it can happen that the LFB is empty but the live filter info bar still is visible and displays something. "

I still could not reproduce it but it's on my list.

Normally (on short and simple listings) the Live Filtering process is so fast that it is hard to hit Esc during the filtering process.
But if you try to apply LFB on a huge branch view (even on a local SDD, e.g. branch view of folder "AppData" in the current user folder - gives me ca. 70,000 items), it will most likely take a while for the filtering to run. Then one can easily hit "Esc" while it is running.

The results are not always the same for me, though (obviously it behaves slightly different on this local path than on the network path).
-) There is a realistic chance that, as mentioned, the live filter info bar is shown with noting in the LFB.
-) Mostly, though, Esc does not seem to have an immediate effect at all. I may hit it again and again. Eventually the window might get blurred out with a rotating circle at the mouse cursors position, not responding at all anymore. Or else the filtering process seems to stop and then seems to start all over again. Sometimes I also cannot even interpret what is going on, just hoping for XY to return command of the bridge back to me again asap.

However, those are bugs I can live with (no high priority for me), since, as it seems, they surface in an annoying way only if applied to huge lists, maybe even on branch views only. I don't have such huge lists w/o branch view. And if I want to apply it to a huge branch view (which probably is not so often) then I know that I have to be patiently waiting for the filtering processes to finish.

The most important still was the LiveFilterDelay. In general Live Filter, LFB and its new options seem to work quite well. Thx again.

This new feature of the live filter box was something that I was expecting some years ago. And finally here it is.

But this opens a door to a new step that I think should be made and that no other file manager has done before:

The use of live filter box do dig in all the lists managed by XYPlorer so that you can find any file or folder wherever it is in the recent locations list or address bar or recently opened files or favorites, etc

Something to think about.

admin wrote:That's a Branch View Setting: Configuration | Find Files & Branch View | Branch View | Let folders pass all filters

...so the other way round, ie 'folders only', is buggy, as it is not respecting the setting and it does allow live filtering of folders.

Anyway, the setting should be ignored when LFB is active: it's just expected that whatever is visible, it should be filter-able regardless of any active setting IMHO.

Could we make a slight change? I originally said that after entering a folder the LFB resets back to nothing.
I think it should be, after entering a folder the LFB gets cleared and focus goes back to the listbox. The idea is that you are reset back to the state of working and not live filtering once you reach your destination. It's a small difference. Most notable difference is that Tab toggles back and forth between the 2 panes instead of circling around through Catalog or the tree (if it's visible).

Also, if possible the up/down keys would focus the listbox so that tab would toggle between the panes and also spacebar and ctrl-space selects files.
I already see that this will change the coding logic, because if I use LFB and then just tab a few times back to the listbox, then ESC doesn't clear the LFB.

The LFB will stay in the current state for a while during which I will collect more opinions.

This is fantastic! Thanks for suggesting and implementing.

klownboy wrote:Don, obviously I could learn to live with it the way you set it and I realize you mentioned that in the release notes. Given the fact that with "Redirect typing..." option ticked, the LFB activates on typing, would be it be possible to have the second press of "Esc" remove the LFB. It actually kind of makes sense since you now have it activated /displayed automatically when you type anyway. So the first "Esc" clears the LFB and the list contents go back to normal. A second press of "Esc" removes the LFB and Status bar if it wasn't displayed previously. If you want to live filter again, you just start typing...it would be more of an on demand type feature that way. You don't have to see the Live Filter Box when it's not being used. What do you think?

Took some time but now I think: yes. Comes with next beta.

Thanks Don. I was wondering though will the second press of Esc also remove the Status bar, but only if the Status bar was not previously displayed prior to invoking LFB by typing? A couple of my layout for photo viewing have no Status bar so it would be nice to have that second press remove the Status bar along with the LFB. When the Status bar is on (for the layout) when they started typing, it should probably stay on when the LFB is removed for obvious reasons (like status).

Yep, it will.

(My setting is TypeAhead redirected to LiveFilter box)
1. If I double click on the LiveFilter bar, I would prefer the disappearing LiveFIlter box.
2. I haven't managed to like the 2 presses of ESC button. It is so superfluous. When I click ESC one time, LIveFilter box should get hidden. It will appear again when I start typing. The phase when it simply goes back to the LiveFilter box waiting for a new input is just unnecessary using the setting above.

LittleBiG wrote:(My setting is TypeAhead redirected to LiveFilter box)
...
2. ... the 2 presses of ESC button. It is so superfluous. When I click ESC one time, LIveFilter box should get hidden. It will appear again when I start typing. The phase when it simply goes back to the LiveFilter box waiting for a new input is just unnecessary using the setting above.

I agree 100,000 % and I thought that this would be clearly logical so I never said anything. But obviously it makes sense to cast in my vote now.

LittleBiG wrote:(My setting is TypeAhead redirected to LiveFilter box)
2. I haven't managed to like the 2 presses of ESC button. It is so superfluous. When I click ESC one time, LIveFilter box should get hidden. It will appear again when I start typing. The phase when it simply goes back to the LiveFilter box waiting for a new input is just unnecessary using the setting above.

+1

OK, I agree with both.

Only with the second. The mouse action (dbl-click) should not hide the LFB.

thx