Update status bar while quickfilter/search active

[Hacker]

Hi,
When the quickfilter or quicksearch are active, and one moves between the files using up/down arrow, the status bar is not updated. I don't recall anyone mentioning that. Is this by design?

TIA
Roman

[StatusQuo]

Hm, you mean in brief view mode (display of current file name/data in status bar), while the search dialog is displayed?

The status bar is indeed not updated then, but most of the status line is covered by the dialog anyway.
After closing the dialog (with quickfilter still active) the status bar is updated again on cursor moves here.

[JohnFredC]

most of the status line is covered by the dialog anyway

Yet another reason to have dedicated subpanels in each file panel a la SpeedCommander and other TC competitors.

[ghisler(Author)]

You can close the quick search dialog with ESC if you need to see the status bar. The quick filter will remain active until you press ESC again. There is no need to update the status bar while it is hidden anyway.

[Hacker]

Christian,

There is no need to update the status bar while it is hidden anyway

Ahem, sorry Christian, but the very existence of this topic shows that I have felt the need to have the status bar updated even while quicksearch/filter is active. Here it hides only the beginning of the file name, important details like size and date are very much visible but unfortunately not updated. This way I have to close and invoke the filter everytime I want to check if there is some specific file among the matching. I know I could switch to full view, but that is annoying, too. Please change this behavior.

TIA
Roman

[Hacker]

[mod]Moved to the Bug Reports forum.

Hacker (Moderator)[/mod]

[ghisler(Author)]

Sorry but I don't consider this as a bug. The behaviour is intentional, and I have described why it works like this. Updating the status bar would cause a slowdown at least when showing the total/selected number of files.

[JohnFredC]

.Updating the status bar would cause a slowdown at least when showing the total/selected number of files.

The issue shouldn't be solely about the speed of TC, but the speed of TC within the context of the given task (of which TC is only a part).

A task with TC (or any file manager) has several components: the goal to be accomplished (i.e., "make more space on drive d: ), the strategy ("move files to another drive"), identification of the sources and targets of the task (files, folders, drives, for instance) and how their characterisitics (sizes, dates, etc) affect the strategy, the execution of the task (including the actual selection of the sources/targets and various options for the activity to perform), and the verification of the success.

The TC development vector should always aim for better functionality within this bigger picture, not just the speed of a specific performance characteristic (which may or may not have direct relevance to the task at hand).

[icfu]

TV remote controls are suffering from slowdowns because fingers have to be bowed. You can save 0.5 seconds by standing up, walking to the TV and switching it on with your feet.
If you don't believe me, ask ghisler! No sh**, Sherlock!

*facepalm 3748*

Icfu

[Hacker]

[mod]Moved to the Suggestions forum.

Hacker (Moderator)[/mod]

[MVV]

Sorry but I don't consider this as a bug. The behaviour is intentional, and I have described why it works like this. Updating the status bar would cause a slowdown at least when showing the total/selected number of files.

Maybe TC should clear status bar instead of leaving outdated? This won't confuse user at least.

[Hacker]

Maybe TC should clear status bar instead of leaving outdated? This won't confuse user at least.

Please don't. Changing a useless state into another useless state is quite... useless.

Roman