Bug 193847 - Status bar text is not updated when navigating files using keyboard after a file operation
Summary: Status bar text is not updated when navigating files using keyboard after a f...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Fedora RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords: reproducible
: 263569 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-05-24 08:48 UTC by Syam
Modified: 2011-03-24 22:43 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Syam 2009-05-24 08:48:47 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Fedora RPMs

Steps to reproduce:
1. Navigate to a directory having some files
2. When mouse-hovering over the files, the filenames are displayed on the status bar - good
3. Select one file
4. Now, using arrow keys on the keyboard, move the selection. The filename of the currently selected item is displayed on the status bar - good
5. Delete a file OR create a new file/directory
6. The status of the operation is displayed on the status bar (Eg: "Created folder")
7. Now, without moving the mouse, repeat step 4.
8. The statusbar text doesn't change! -  not good
9. Move the mouse over some icon, everything gets back to normal
Comment 1 Syam 2009-06-13 14:21:13 UTC
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.
Comment 2 Raphael Kubo da Costa 2010-01-21 04:26:02 UTC
For the record, comment #1 is actually bug 185186.
Comment 3 Daniel Mader 2011-01-18 21:43:33 UTC
*** Bug 263569 has been marked as a duplicate of this bug. ***
Comment 4 Frank Reininghaus 2011-01-19 12:23:03 UTC
This also happens when renaming a file, see bug 263569.
Comment 5 Sebastian Dörner 2011-03-23 00:56:14 UTC
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?
Comment 6 Peter Penz 2011-03-23 08:28:04 UTC
@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.
Comment 7 Sebastian Dörner 2011-03-23 12:17:43 UTC
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.
Comment 8 Sebastian Dörner 2011-03-24 22:43:37 UTC
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