Version: 4.1.0 (using KDE 4.1.0) Installed from: Ubuntu Packages Please see attachment, it should be self explanatory. The regression is that the click/target area for selection in konqueror when operated in detailed/tree view mode has shrunk down from a relatively comfortable size in kde3 to a very uncomfortable tiny area in kde4.
Created attachment 26638 [details] konq 3 vs 4 regression illustration
Reassign to Dolphin since Konqueror now uses the Dolphin kpart.
This is intended from a Dolphin point of view, as otherwise it won't be possible to deselect all items by pressing on the viewport area. I've changed the severity of this report to "wishlist". BTW: it is still possible that someone writes other file-view plugins for Konqueror, so not each request must be fixed in the Dolphin KPart necessarily.
That seems like a weak argument to me. What is the purpose of deselecting all items? What is achieved by that? And how is that more important than selection?
> What is the purpose of deselecting all items? It prevents an accidental moving of items when using drag & drop. Usecase: - open a directory with a lot of items in the details view - open a text file to check the content - scroll down a few pages - select items by using the (+) items (or like you suggest: by clicking on the other columns - assuming that this would be possible) - drag the items to another folder and select 'Move' Result: the text file you've only opened to check the content will be moved too However I don't claim that the current solution is the perfect solution. My intention was to have a consistent selection behavior between all views (icons view, details view, column view). I'm open for improvements but I also need to take care not taking away a functionality that has been offered since KDE 4.0. I can imagine that I provide an option for your suggestion, I just want to wait a little bit until I get an impression how many people claim to have this feature...
Created attachment 26654 [details] konq selection mockup I think there is room for both. Consider this suggestion (see attachment). The open click area is preserved from konq3. The select click area is the rest of the cell. The deselect click area is the rest of the row. Btw, I find it troubling that you are concerned about regressing from KDE 4.0 but not KDE 3.x. :(
Thanks for the suggestion, I'll consider it. > Btw, I find it troubling that you are concerned about regressing > from KDE 4.0 but not KDE 3.x. :( Sorry, but this comment is nonsense. I never said that I'm not concerned about regressions in KDE 4 in comparison to KDE 3. What concerns me is the you assume that all people prefer the KDE 3 approach to the current KDE 4 approach. This is definitely not the case and I can found this statement by the input I got from users (my mailbox currently counts 8000 Dolphin/Konqueror related e-mails). So talking about "regression" is for sure OK from your personal point of view, but please don't apply your view to all people out there. BTW: I don't want to abuse this bug report as discussion forum and prefer spending the time on fixing issues ;-)
I have no interest in making this a personal issue. If you say you have no intention of doing anything about it then I take your word for it.
> If you say you have no intention of doing anything about > it then I take your word for it. *sigh* I'd suggest that you stop putting things into my mouth which I never said... You did this already the second time within this bug-report.
I just started testing kde4 ( using kde42.debian.net packages ) and since konqueror as file manager is one of the apps i use most in kde i also miss the behaviour i am used to a lot. so from my side there is also a big wish for finding a way to at least optionally get the old behaviour back.
Is this a dupe of https://bugs.kde.org/show_bug.cgi?id=145358 ?
*** Bug 230999 has been marked as a duplicate of this bug. ***
*** Bug 253527 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Is this a dupe of > > https://bugs.kde.org/show_bug.cgi?id=145358 Yes, it seems so. *** This bug has been marked as a duplicate of bug 145358 ***