Version: (using KDE KDE 3.5.5) Installed from: Ubuntu Packages I am using KDE 3.5.5 with "single click to execute". In Konqueror (and also in the KDE file open dialog, used by e.g. Kate), "Shift+click" works in a very uncomfortable way. Files get _removed from the selection_ under various conditions, which, in my opinion, should not occur while using "Shift+click". In other words, "expanding" the selection does not work as expected. Expected behaviour: - Click = Select. - Ctrl+click = Add file to selected. - Shift+click = Broaden the selection to contain the newly clicked file _and_ the files in-between this and last selection. This should not remove any previous selections. I will give an example of expected "Shift+click" behaviour, where we have two or more files / groups of files selected, and _unselected files between these_. In the example, "x" denotes a selected file, "X" denotes the one we (Shift/Ctrl+)clicked on last, and numbers denote unselected files. "Y" denotes the file we "Shift+click" immediately after "X", and which becomes our new "last clicked file". We have a selection like this: xxxxx123456xxxxxX789xxxx. So, if we now "Shift+click" on "3", we expect the files between and including "X" and "3" to be selected, after which we would have: xxxxx12Yxxxxxxxxx789xxxx. What actually happens, is different, and I'll describe here the two different behaviours in Konqueror's different view modes. 1. In Konqueror's "Icon view" and "Multicolumn view" (N.B. This is also how the "Open file" -dialog behaves!): - We can "Click" or "Ctrl+click" as we like, and this works as expected. - When we "Shift+click", only the files between "X" and "Y" are selected, and _selection is removed_ from other files! - We can continue our "Shift+click" travels in the dialog, and always _only_ the files between our two last "Shift+clicks" will be selected, and the rest are _de-selected_. - In sum, instead of "expanding" the selection with "Shift+click", the selection "travels" along. (N.B. The files are also selected in a rectangular manner, but that is a different issue, see bug 59228. This report is only about files being removed from selection while "Shift" has been pressed.) 2. In Konqueror's other views (detailed file list view, list view, tree view, text view): - We can't directly "Click" on a file, because that would execute it. (Well, we can, mostly, which gets the file selected anyway, besides opening it in e.g. Kate.) - We can also click _beside_ the file, or "Ctrl+click" on the file to select it. - We now have selected a file, let's call it file "A". - If we now "Shift+click" below this file, it appears to work as designed. - However, if after this we "Shift+click" _above_ file "A", we see that the selection is changed to contain the files from "A" upwards, including file "A", and the selection from "A" downwards is again _removed_. - You can also demonstrate this behaviour by "Ctrl+clicking" on a number of distinct files, with unselected files in between, and after that start "Shift+clicking" above and below these files. You will see that files will get removed from the selection as you proceed. - Again, instead of "expanding" the selection with "Shift+click", the selection "travels".
I will now comment on the relations of this bug and some related bug reports. Bug 126065 is related. It talks about difficulties in "selecting discontinuous blocks of files". Fixing _this_ bug, thereby creating a more usable "Shift+click" selection behaviour, would also provide a solution to that bug. Bug 114529 is related. It talks about _deleting files_, and how "Shift+Right_clicking" "causes the file selection to change". Bug 45556 talks of related difficulties in "Shift-selecting" files, but _with the keyboard_, and also questions why "Shift-selecting" actually removes files from the selection. Bug 20192 actually talks about the issue of the selection "traveling" with "Shift+click", but the report is six years old, and closed as fixed (rather as "worksforme", judging by the comment). Finally, bug 20194 has a confusing relationship to this bug. This is because, as far as I can read, the original report and the comments (that are dated three years later) are unrelated to each-other. - The _original wish_ (Feb 2001), is how things actually work, now. And there's nothing bad with it, if shift wasn't released in-between. So, as the _original wish_ has been FIXED, that report should, in my opinion, also be marked as FIXED. - _All the comments_, however (starting from January 2004!), lament and regret how "Shift+click" works in an "unintuitive" way. Much like this report. To the best of my understanding, as said, these comments are however, at most undirectly related to the original issue in _that_ report. The comments from that bug would seem better at home here, which is what I will suggest, as there is no other open bug report directly concerning the uncomfortable "Shift+click" selection behaviour.
One more issue. Talking about "Shift+click" selecting / de-selecting files, I think it actually should make a difference, whether or not the "shift" -key has been released between clicks. If this is addressed, "Shift+click" can actually _de-select_ files. The problem with how the thing works, at the moment, is that files get de-selected _without_ the user explicitly wanting this! The difference in behaviour is best expressed by two examples. If "shift" _is kept pressed_ throughout, the following would, IMO, be logical: - We have files 1234567. - We press "shift", and keep it pressed. - We "Shift+click" on "1", then "7", then "4", then "5". - We release "shift". Result: - We should have files "12345" selected, because (during the same "shift+select" action), our _first_ selection was "1" and our _last_ selection was "5". If we _release_ "shift" in-between the process, this should, instead, happen: - We have files 1234567. - We press "shift", and "Shift+click" on "1", then "7". - We release shift, and now have files "1234567" selected. - Now, we press "shift" again, and "Shift+click" on "4", then "5". This should _de-select_ the range of files "45". Result: - We should now have files "123" and "67" selected.
As the original submitter, considering especially my previous comment, I would like to make this request. N.B. Please change the title of this bug to the following: - "Shift+click" _de-selects_ files in Konqueror without the user explicitly wanting this
PLEASE NOTE: My initial submission has a mistake _in the examples_. Instead of the way it's presented there, I would prefer the way I described in comment #2. The problems with unintended de-selections and the selection "traveling" are still valid.
I wish I could edit the initial subscription. But to illustrate, and reinforce what I said in comment #2, this is what I think would be the preferable "expected behaviour" for "Shift+click": - "Shift+click" always requires (at least) two clicks to define the range. - If the first item clicked on gets unselected, so does the entire range. - And if the first item clicked on gets selected, this is similarly done for the entire range indicated by the last click. - Releasing "shift" should confirm the selection. - Selections outside the range should not be affected. The tricky part in implementing this is, if we have a range with both selected and unselected files, over which we operate. If "shift" is kept pressed for the duration of the process, no matter how many times we click, only the range between our _first_ and the _last_ click should be selected/de-selected. Ideally, this would mean that the pre-existing selections should be remembered, until "shift is released". To illustrate: if we accidentally first select a larger area than intended (but don't release "shift"), we can alter the selection to contain a smaller area, and the selections outside this area should be reverted back to what they were before we started our "shift+click" procedure.
Reports about file management mode reported against KDE 3 (konqueror) has been closed: konqueror in KDE 3 is no more developed and mantained. All bugs and wishes which could be interesting for Dolphin in KDE 4 (the new KDE file manager) has been collected into a specific list. Please try the new file manager before request new features and report bugs. Before submitting new reports check carefully the already opened Dolphin reports in order to don't add duplicates. Many thanks.