Bug 270606 - hovering over searched files shows weird behaviour
Summary: hovering over searched files shows weird behaviour
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Unclassified
Component: search (show other bugs)
Version: 16.12.2
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-10 18:17 UTC by Christian González
Modified: 2011-04-16 15:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.0


Attachments
Video showing the problem (736.91 KB, video/ogg)
2011-04-10 18:17 UTC, Christian González
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian González 2011-04-10 18:17:56 UTC
Created attachment 58774 [details]
Video showing the problem

Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

I navigated into /usr/share/icons and pressed Ctrl+F for Search. as search pattern I filled in "home*.png", but should do with any other common name too.
Nepomuk found many files and listed them into the dolphin view.

But when hovering over a file, Dolphin behaves very weirdly, see video.
It seems as if the file with the mouse over it seems to get "deleted" from the list, as following files fill up the line (see video).
When the mouse is out of the view field (e.g. hovering over the tab bar), key naviating in the files works as expected. But as soon as the mouse enters the view, everything goes "crazy".

Tey are not deleted really, I dont't have write perms on that dir though.
On the video I just hover on and off one file, I don't press any key.

Reproducible: Always

Steps to Reproduce:
search for home*.png in /usr/share/icons with Nepomuk/Strigi on.

Actual Results:  
see above.

Expected Results:  
Files should not disappear.

OS: Linux (x86_64) release 2.6.35-28-generic
Compiler: cc
Comment 1 Christian González 2011-04-10 18:35:28 UTC
I just saw that this has nothing to do with nepumuk or searching. just navigate to /usr/share/icons/Tango/32x32/places/, dolphin shows same beaviour.
Maybe it has something to do with symlinks in the dir?
Comment 2 Christian González 2011-04-12 21:57:38 UTC
Sorry, wrong one, it is just in the search.
Confirmed in Kubuntu Natty beta too.

Important is, switch preview on, goto /usr/share/icons, search for "home" (or something else), let the search finish, and move the mouse over the icons.

It seems to me that only files with the same file name are rotating. Maybe the view doesn't know how to order them? Off-By-One bug in the ordering routine (just guessing)?
Comment 3 Peter Penz 2011-04-13 08:20:20 UTC
Thanks for the report, you are right with your guess that this is a problem with the ordering of the items: Each item inside a directory must have a unique ID for ordering, which does not seem the case here. I'll have a look on this during the next week...
Comment 4 Peter Penz 2011-04-16 15:27:19 UTC
Git commit 48c4a5a7ddf8cb79f9b24e0adc3deeb1154c800a by Peter Penz.
Committed on 16/04/2011 at 15:31.
Pushed by ppenz into branch 'master'.

KDirSortFilterProxyModel: Fix sorting issues for e.g. search-protocols

For a e.g. search-protocol comparing KFileItem::text() or
KFileItem::name() is not sufficient as it may
show different files with the same filename in parallel. To assure a
defined order a comparison of the URLs is done as fallback.

BUG: 270606
FIXED-IN: 4.7.0

M  +12   -8    kfile/kdirsortfilterproxymodel.cpp     

http://commits.kde.org/kdelibs/48c4a5a7ddf8cb79f9b24e0adc3deeb1154c800a