Summary: | Places view in KFileDialog highlights closest match, rather than only highlighting on exact matches | ||
---|---|---|---|
Product: | [Applications] kfile | Reporter: | Stephan Sokolow <kde_bugzilla_2> |
Component: | kfileplacesview | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aseigo |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Screenshot showing the problem
Mockup for proposed compromise |
Description
Stephan Sokolow
2009-02-06 02:10:28 UTC
Created attachment 31011 [details]
Screenshot showing the problem
Correction: I don't have to go AFK for it to regain its effectiveness. I got stuck for roughly 2 seconds while trying to select this file because habit says that clicking on an already-selected places entry will have no effect, but I wanted to get to Home so I could go to the desktop.
this is intentional for a few reasons, consistency being one of them, and is much clearer when using the breadcrumb navigation rather than the editable url navigation. My point is that the current behaviour is inconsistent with both GTK+ and KDE 3, Hence the disorientation I mentioned. Would it preserve consistency acceptably if there was a single toggle (even just one that's only available via raw rc file editing) which changed the behaviour everywhere a places view is used? If it would but you don't feel it's worth the effort, would you accept a patch to provide such a hidden toggle? (I don't know how soon I'd be able to write one, but it should be simple enough for me to pull off if I do manage to make time.) If not, what about introducing some kind of obvious visual distinction in the places entries between "active, current folder" and "active, ancestor of the current folder". ...or, if I really do have to just close the places sidebar and use the bookmarks menu, could it at least be altered so bookmarks can be visiblity-limited to a specific application the way places are? (The lack of that feature is by far my biggest complaint about the GTK+ 2.x and vanilla Qt 4.x file pickers) Now that I'm not half-way through an all-nighter, I'm a little more receptive to the new design, but I still think there should be some sort of visual distinction between directly viewing a place and having it as the ancestor of your current location... if nothing else, to bring some consistency with every other Save/Load bookmarking implementation that it may coexist with. The KDE 3.x, vanilla Qt 4.x, and GTK+ 2.x Save/Load dialogs all encourage the assumption that highlighted means current location. Created attachment 31069 [details]
Mockup for proposed compromise
Would one of the two appearances for "current location" in this mockup be an acceptable compromise?
*** This bug has been marked as a duplicate of bug 156678 *** |