Dual view lag and other "unresponsiveness"

Help & Support
1

I noticed four things (I am a bit picky I admit) that make the dual view and some other parts of Directory Opus feel "laggy" or "unresponsive" or "obtrusive" sometimes and that I think could be fixed rather easily:

  1. When a directory is loading (say, slowly from a network drive) and I enter a filter such as "*.zip", then if the loading completes while I am typing my filter, whatever I typed so far is reset. With reset I mean the characters I typed until that point vanish. I think my current typing should never be disturbed, regardless of what happens in the lister view.

  2. If the left half of the dual lister is refreshing slowly, the right half also becomes unresponsive. I think the left and right half should be independent of each other's refresh status.

  3. When copying files, the copy dialog that pops up is fixed to be always on top of the current lister, even though it is completely asynchronous and the underlying lister is fully operational. I should be able to move the lister in front of this copy dialog, but I seem to be unable to do so.

  4. When using customize, the customize dialog is fixed on top of the lister I used to invoke it. This is extremely annoying and probably related to 3)

2

  1. It wouldn't work anyway since you're applying a filter to nothing, and the filter would be cleared when the new folder loads. You need to wait until the folder has loaded before you filter it.

  2. The two sides are largely independent, but can't be entirely as they do share the same window, status bar, toolbars, etc. It's also possible that shell extensions are causing problems, e.g. if they are not designed to be used in parallel by multiple windows and make each one wait in a queue if another makes a request that is slow.

  3. Turn on Preferences / File Operations / Progress Indicators / Minimize progress indicators and the option above it to display the jobs bar.

  4. The Customize dialog is on top of all Opus windows by default, not just the one that opened it. You can change that via the Keep On Top menu. Button Editors will remain on top of everything regardless, because they have to be able to edit things on menus and on-top windows and would sometimes end up lost behind the thing they are editing otherwise.

3

Thank you very much, those answers actually helped a lot. I wasn't aware of the jobs bar and it was exactly what I needed.

Only the filter issue remains, and it is not that big of a deal I guess.

4
  1. Button Editors maybe could popup on top of everything else, but maybe they don't need to keep that frontmost-position? I find them really annoying for years. Especially if you switch to another application to copy code/text/paths from there to paste it into one of those button editors. Or while the chm-manual is open. It always leads to a window-move/drag orgy, even worse in case you have multiple button editors open.

If a button editor is opened for things on floating toolbars or something, which maybe requires the window to be on top of everything else, the current behaviour could be restricted to these special situations. For most of the edits on regular buttons, I see no reason for the "ontop" thing, but I admit, I may not be fully aware of the reasons behind that. o)