Version: 4.00.85 (KDE 4.0.85 (KDE 4.1 >= 20080703) "release 3.3" (using 4.00.85 (KDE 4.0.85 (KDE 4.1 >= 20080703) "release 3.2", KDE:KDE4:Factory:Desktop / openSUSE_10.3)
OS: Linux (i686) release 184.108.40.206-0.1-default
In kde3-Konqueror-Version it was possible to start multiple-file-selection with left-mouse-button-pressing in empty-space (without filename-text) of the file-name-column. in kde4-version this action moves the file, from which the mouse-dragging starts. I liked much more the old behaviour. I copied several folders by accident because of this.
Only solution: holding ctrl when doing this. but even this does not work properly: the dotted-rectangle is not displayed in this case, at least this seems to be a bug.
Using KDE 4.1.1 (KDE 4.1.0 (4.1 >= 20080722)) (KDEmod) in ArchLinux i686:
I can reproduce this behaviour. To select some files in the Konqueror detail view you have to start the select rectangle in a empty-space (no file rows) or in a column other than the file-name-column.
May be this is the default new behaviour and this would be marked as a wish.
IMHO it is a (usability) bug, if it leads to unexpected behavior even if used by those having used KDE(3) for years. And this is not the only instance. There have been made a LOT of changes that make KDE behave more gnomish or vista like. Everytime i'm bringing this up i am either ignored or being told: 'if it bothers you why don't you commit patches', or 'most people prefer it this way'...
regardless of what most people prefer, for one, the KDE UI should be made more efficient again, exposing MORE customizability and information everywhere, at the same time providing more GUIDANCE for users to learn how to use it, and settings to simplify the UI that are NON-DEFAULT, because a feature that is useful but hidden by default is as good for 85% of the people as not having it at all. I am still unsure if i should fork my personal 3.5 tree or continue report to BKO reports that are closed 'won't fix' or 'by design'.. where are the authors that originally made konqueror and kicker that much of a efficiency beast? heck i'd even PAY them to port features and evaluate power-usability.. if not all my resources where bound by working on drupal and hfopi.org, i'd do it myself..
See mini-discussion here:
Both Peter and I dislike the current behaviour (it's not "by design" by the Konqueror developers; it's simply the default way that QTreeView works in Qt4). I hope to fix it as part of my work on fixing feature regressions in KDE4 Konqueror, but the fix will likely be non-trivial so I can't give an ETA, so please have patience :)
SVN commit 871834 by ppenz:
First step for having a details view, where only the icon + name act as selectable area (not the whole width of the name column - similar to KDE3). Thanks to Simon St. James for the original patch!
Currently it is very confusing that although only the icon + name is selectable, still the selection and hovering is drawn above the whole column width. This will be fixed before KDE 4.2.
M +120 -11 dolphindetailsview.cpp
M +15 -3 dolphindetailsview.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=871834
SVN commit 871874 by ppenz:
Assure that the item delegate draws the hover effect and the selection for the details view only above the icon + name. Open issue: The performance when selecting files by the rubberband is too slow (will be fixed before KDE 4.2).
M +3 -2 CMakeLists.txt
M +7 -11 dolphindetailsview.cpp
A dolphinfileitemdelegate.cpp [License: GPL (v2+)]
A dolphinfileitemdelegate.h [License: GPL (v2+)]
M +3 -2 dolphinview.cpp
M +2 -2 dolphinview.h
WebSVN link: http://websvn.kde.org/?view=rev&revision=871874
Hi, just read about that fix in the KDE Commit-Digest - great news.
Could someone probably check if this even fixes #145358 - i have no recent SVN Build at hands.
If its not collateral fixed, maybe a fix would now be very easy.
this seems to be fixed.