(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: 3.0.6 (KDE 3.0.6 (using KDE 3.0.6 ) Severity: normal Installed from: compiled sources Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.19-rc1 OS/Compiler notes: Selecting files only with the keyboard in the detailed list view mode which I like to do does not really work like I expect it to. Try this: Mark a file with the mouse. Now press shift and cursor up or down. What I expect now is that there are two marked files the first one by mouse and the second by keyboard. But what I see is that there is one marked file and the selection box has moved. Is there any reason not to select the "boxed" file as well? I cannot imagine any. Could you please change this behaviour? What I like very much is moving the selection box with the cursor keys and selecting the files with the spacebar. But this should not disturb the shift-cursor-selection-behaviour right? (Submitted via bugs.kde.org) (Called from KBugReport dialog)
This bug was fixed in KDE 3.1.x and now re-appears in KDE 3.2. Is there anybody working on this. What caused the regression?
can confirm this in KDE 3.3.2, to....
It still seems to be unchanged in KDE 3.4.1. I would really like it if the keyboard handling would be exactly the same as in windows, since this allows to effectively use the keyboard in the list view.
bug 82494 is a duplicate of this one. Regarding comment 3, the behaviour was the same but changed to some regression. However nobody seems to be interested enough in this in order to fix it.
What a pity. Keyboard navigation is really unusable, one has to go back and forth to select files. This is one point where windoze is undeniably better. Is there no developer using the keyboard in Konqueror in list view?
*** Bug 82494 has been marked as a duplicate of this bug. ***
The behaviour is as follows: space: toggle selection of the current file insert: toggle selection of the current file and move to the next file shift+up/down: deselect what was selected before shift was pressed, select the current file and move to the next/previous file ctrl+up/down: select the current file and move to the next/previous file Alex
> shift+up/down: select the current file and move to the next/previous file And this is inconsistent with KDE itself! Please switch to icon view, ctrl+click on a file and then move around with cursor keys. Completely different to list view! The current file in icon view is always selected! Then please do shift+right or shift+left. Right, the next icon will be the current one and will also be selected! Apart from the obvious inconsistency, the behaviour of list view is stupid, confusing and used nowhere else. This toggling with space in list view is quite nice, so without shift you can divide current and selected, but to differentiate between current file and selected file _when_holding_down_shift_ is no use at all, only confusing. And, you don't need it for the space toggling functionality. Selecting in list view with shift is a p*in in the *ss, every time again. Sorry, but this bug is annoying me the last 5(?) years or so, far too long to stay calm. Please change it for the sake of consistency and for the user who knows it different from some other file manager. Or, please, make it selectable in Konqueror's configuration. Just think about all those votes and duplicates. The users really want it to work the "normal" way.
This is absolutely not an wishlist item! It worked different before and I could not find any wishlist item, to change the behaviour to the current, so why was it changed, if it is not a bug. Apart from the inconsistency with the icon view, which other file-browser handles it the way konqueror does in detailed-list-view? But anyway, here come some examples: Open konqueror, select a file by clicking next to it, press shift+down: The first file stays selected, the second gets selected. Bravo, expected behaviour! Use that same konqueror-session and do the same thing again: Select a file by clicking next to it, press shift+down: The first file gets de-selected, the second selected. How come? The user did exactly the same thing, yet there are two different behaviours. Another approach: A user clicks on a file, or selects it with space. Why would the user press SHIFT? Because the currently selected file should be kept selected when going up/down. If the user would not want that, why should s/he press shift? Why would the user not only press SHIFT, but also up/down? Because s/he wants the current file kept selected (SHIFT) and the one above/below it selected too. If s/he would just want to keep the first one selected and not the one above/below, then why would s/he press SHIFT and not simply up/down?
some developer feedback would be nice
Hello. Looking at the original submission and the comments, it seems there are a couple issues here, one being the (original submissions) interaction between "mouse-selecting" and "keyboard-selecting", and another being the problems with "shift-selecting" on the keyboard. Please see also bug 142791 about the discomforts of using Konqueror's "Shift+click" -behaviour. The report is mouse-centric, but the issue of "shift+selecting" has an obvious and immediate connection to this report. This is, in my opinion, a serious usability issue.
SHIFT select and other selecting cases doesn't work well in KDE 4 too. Some will works correctly when Qt 4.6 will be available for KDE 4. There already exists specific bug reports for dolphin/KDE4. I suggest to mark this as unmantained or wontfix for Konqueror in KDE 3.
This specific bug anyway is not reproducible in KDE 4 trunk.