Bug 301252 - After cancelling or finishing inline renaming, I can't use arrow keys for moving focus.
Summary: After cancelling or finishing inline renaming, I can't use arrow keys for mo...
Alias: None
Product: dolphin
Classification: Unclassified
Component: general (show other bugs)
Version: 2.0.95
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Peter Penz
: 302157 302321 (view as bug list)
Depends on:
Reported: 2012-06-06 00:46 UTC by Jekyll Wu
Modified: 2012-06-22 02:39 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.0


Note You need to log in before you can comment on or make changes to this bug.
Description Jekyll Wu 2012-06-06 00:46:17 UTC
Normally, I can use arrow keys for moving  focus between files. But after any attempt of inline renaming, I can't do it any more.

This is quite annoying, since it makes it impractical to use dolphin with keyboard only.

Reproducible: Always

Steps to Reproduce:
1. Enter some folder containing multiple files.
2. Use arrow keys to move focus to any file (say, the last one)
3. Press F2 to start inline renaming
4. Press Esc to cancel inline renaming, or press ENTER to finish inline renaming
5. Try to use arrow keys to move focus from current file to other files.
Actual Results:  
I can't. Arrow keys just stop working. I have to use mouse to select some file, then arrow keys work again.

Actaully, the 'Menu' key(for poping up the context menu) stops working after inline renaming, too.  I guess it shares the same cause .

Expected Results:  
Arrow keys should still work just like in step 2.

This happens in all of icon view, compact view and details view.
Comment 1 zless 2012-06-06 19:20:02 UTC
I confirm this with Archlinux KDE 4.9 beta1
Comment 2 Peter Penz 2012-06-08 14:42:23 UTC
Thanks for the report, this has just been fixed by commit 2e057eb6e21fe850c101a1f2bedaffd986ffdf3a (forgot to add the bug-number in the commit-message).
Comment 3 Frank Reininghaus 2012-06-08 14:56:09 UTC
Funny, I was just working on the same thing :-) And I think that I found a problem that your fix does not address, Peter:

If the renaming is cancelled, e..g, by clicking another view in split view mode or the Places Panel, the new focus widget should keep the focus, but at the moment, the DolphinView just steals it.

My approach was to add the following code in KStandardItemListWidget::slotRoleEditing* (looks less elegant than your solution though):

if (m_roleEditor->hasFocus()) {
    // If the editing was not ended by a FocusOut event, we have
    // to transfer the keyboard focus back to the KItemListContainer.

Maybe we can find a way to replace the ugly line by something that invokes DolphinView's setFocus() slot.
Comment 4 Peter Penz 2012-06-08 20:50:48 UTC
Thanks Frank for noticing this issue, you are of course right. Although you say your solution looks less elegant than mine, I think your solution is the better one :-) This kind of focus-handling should be done internally by the KItemList* classes and not externally by the DolphinView like with my approach. The line


looks of course really ugly. I did a very minor cosmetic improvement with: 


but it is still not a beauty ;-) However when I worked on the libmeegotouch-classes I've seen that there it has been done in a similar way and QGraphicsView* does not offer a nicer API for this.

So I've just created a patch with your solution now and will push it.
Comment 5 Peter Penz 2012-06-08 20:51:32 UTC
Git commit 2cfa7298c2501f96cfcf45f0e562696ec818039f by Peter Penz.
Committed on 08/06/2012 at 22:43.
Pushed by ppenz into branch 'master'.

Inline renaming: Improve focus handling

Fix issue that cancelling the inline-renaming by clicking
on the other split view applies the wrong focus.

Thanks to Frank Reininghaus for the initial patch and noticing
this issue.

M  +13   -4    dolphin/src/kitemviews/kstandarditemlistwidget.cpp
M  +6    -0    dolphin/src/kitemviews/kstandarditemlistwidget.h
M  +0    -11   dolphin/src/views/dolphinview.cpp
M  +0    -1    dolphin/src/views/dolphinview.h

Comment 6 Jekyll Wu 2012-06-19 00:10:40 UTC
*** Bug 302157 has been marked as a duplicate of this bug. ***
Comment 7 Jekyll Wu 2012-06-22 02:39:23 UTC
*** Bug 302321 has been marked as a duplicate of this bug. ***