Bug 193847

I have another related observation.
1. Hover the mouse over a file/folder so that it's name is displayed on the status bar
2. Letting the mouse stay on that item, change the file/folder selection by using the arrow keys on the keyboard.
3. The name of the selected items are *not* updated on the status bar. it still shows the name of the item the mouse points to.

For the record, comment #1 is actually bug 185186.

*** Bug 263569 has been marked as a duplicate of this bug. ***

This also happens when renaming a file, see bug 263569.

The problem is in DolphinViewContainer::updateStatusBar(), however it is actually correct behaviour by policy: The status bar message is only replaced for Info-Messages. The "file deleted" message however is of type OperationCompleted.

I see several possible solutions:
1) extend the general replacement policy to InfoMessage || OperationCompletedMsg
2) let some special events like "changing focus using the arrow keys" trigger a special case that also overrides OperationCompletedMessages
3) Implement a longer timeout that wipes the OperationCompletedMessage. However, this would only partially solve the bug as arrow key strokes directly after renaming/deleting (i.e. before the timeout) would still be ignored.
4) Stick with the current behaviour and make the bug "won't fix" as these OperationCompletedMessages are considered too important. However, we would need to enforce this policy for MouseOver as well to be consistent.

Any opinions/preferences?

@Sebastian: Thanks for the analyses. I've not debugged this issue yet but I think the fix should be that navigating the keyboard results in the same update-operation like when hovering with the mouse, which seems to be point 2. So no change should be necessary in the statusbar itself.

Yes, the statusbar itself stays untouched.
The difference is that keyboard navigation triggers a delayedStatusBarUpdate(), i.e. the actual update is invoked through a timer. This is certainly useful for fast scrolling, but the timer is probably also invoked for other events, which should not override OperationCompletedMessages.
In contrast, Mouse hovers trigger DolphinViewContainer::showItemInfo().

I'll see if I can compile a complete list of who issues delayedStatusBarUpdates and see which of them should also override OperationCompletedMessages.

Git commit 09bb41124032aeb85e80f501ed1a766d6e4835bf by Sebastian Dörner.
Committed on 24/03/2011 at 00:45.
Pushed by doerner into branch 'master'.

Make cursor keys always trigger a statusbar update

When the selection is changed using the cursor keys, the statusbar
should be updated. Until now, this didn't actually happen directly after
an operation ending in a OperationCompletedMessage, because the
OperationCompletedMessage was protected.

This patch changes the behaviour to only protect ErrorMessages in the
ViewContainer. When an OperationCompletedMessage was issued very
recently, it keeps being protected by DolphinStatusbar itself.

Statusbar updates in the ViewContainer are only triggered by
a) user actions (move keyboard focus, enter something in the filter bar)
b) finished filed jobs

In case a), the update is desired, also overriding
OperationCompletedMessages.
In case b), the OperationCompletedMessage issued by the file command is
issues so shortly before the call to updateStatusBar, that the
DolphinStatusBar skips the message anyway (see
DolphinStatusBar::setMessage).

BUG: 193847
FIXED-IN: 4.7.0
REVIEW: 100939

M  +3    -12   dolphin/src/dolphinviewcontainer.cpp     
M  +3    -0    dolphin/src/dolphinviewcontainer.h     

http://commits.kde.org/kde-baseapps/09bb41124032aeb85e80f501ed1a766d6e4835bf