| 2007-03-06 09:49:31 |
kko |
bug |
|
|
added bug |
| 2007-03-10 17:16:00 |
kko |
bug |
|
|
assigned to kdebase (upstream) |
| 2007-03-11 07:35:06 |
Bug Watch Updater |
kdebase: status |
Unknown |
Unconfirmed |
|
| 2007-03-13 14:46:58 |
kko |
title |
"Shift+click" _de-selects_ files in KDE "Open file" -dialog and Konqueror |
"Shift+click" _de-selects_ files in KDE "Open file" -dialog and Konqueror without the user's intent |
|
| 2007-03-13 14:49:49 |
kko |
description |
Binary package hint: kdebase
Using Kubuntu Dapper, with KDE 3.5.5, and with "single click to execute".
In the KDE file open dialog (used by e.g. OpenOffice and Kate, among others), and somehow also Konqueror, "Shift+click" works in a very strange 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.
So we will have: xxxxx12Yxxxxxxxxx789xxxx.
What actually happens, is different.
In the "Open file" -dialog (N.B. This is also how Konqueror's "Icon view" and "Multicolumn view" behave!):
- 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. These are also selected in a rectangular manner, see http://bugs.kde.org/show_bug.cgi?id=59228, but that is a different issue. This report is about files being removed from selection while "Shift" has been pressed.)
In Konqueror (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". |
Binary package hint: kdebase
Using Kubuntu Dapper, with KDE 3.5.5, and with "single click to execute".
In the KDE file open dialog (used by e.g. OpenOffice and Kate, among others), and somehow also Konqueror, "Shift+click" works in a very strange 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_.
EDIT: Expected behaviour with "Shift+click" (and the following examples) could be better defined, I will try to see (later) if I can edit the description to better fit this. For the moment, please see my comment from 2007-03-13 14:45:30 UTC.
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.
So we will have: xxxxx12Yxxxxxxxxx789xxxx.
What actually happens, is different.
In the "Open file" -dialog (N.B. This is also how Konqueror's "Icon view" and "Multicolumn view" behave!):
- 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. These are also selected in a rectangular manner, see http://bugs.kde.org/show_bug.cgi?id=59228, but that is a different issue. This report is about files being removed from selection while "Shift" has been pressed.)
In Konqueror (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". |
|
| 2007-03-16 19:54:20 |
kko |
description |
Binary package hint: kdebase
Using Kubuntu Dapper, with KDE 3.5.5, and with "single click to execute".
In the KDE file open dialog (used by e.g. OpenOffice and Kate, among others), and somehow also Konqueror, "Shift+click" works in a very strange 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_.
EDIT: Expected behaviour with "Shift+click" (and the following examples) could be better defined, I will try to see (later) if I can edit the description to better fit this. For the moment, please see my comment from 2007-03-13 14:45:30 UTC.
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.
So we will have: xxxxx12Yxxxxxxxxx789xxxx.
What actually happens, is different.
In the "Open file" -dialog (N.B. This is also how Konqueror's "Icon view" and "Multicolumn view" behave!):
- 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. These are also selected in a rectangular manner, see http://bugs.kde.org/show_bug.cgi?id=59228, but that is a different issue. This report is about files being removed from selection while "Shift" has been pressed.)
In Konqueror (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". |
Binary package hint: kdebase
NOTE: I have edited the "expected behaviour" section of this submission to contain my comment from 2007-03-13 14:45:30 UTC. I have also edited the examples accordingly.
Using Kubuntu Dapper, with KDE 3.5.5, and with "single click to execute".
In the KDE file open dialog (used by e.g. OpenOffice and Kate, among others), and somehow also Konqueror, "Shift+click" works in a very strange way. Files get _removed from the selection_ under various conditions, without the user wanting to do so. Removing files from selection with "Shift+click" should, in my opinion, only occur when the user wants this. In other words, "expanding" the selection does not work as expected.
Expected behaviour:
- Click = Select.
- Ctrl+click = Add file to selected.
- Shift+click = "Shift+click" should always require (at least) two clicks to define the range. I'll elaborate below.
With "Shift+click", 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 the _first_ and the _last_ click should be selected.
Ideally, this would mean that the pre-existing selections should be remembered. So, 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 our "shift+click" procedure.
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" notes the file we last clicked on, and numbers denote unselected files.
We have a selection like this: xxxxx123456xxxxxX789xxxx.
So, if we now "Shift+click" on "3" and then on "6", and release "shift", we expect the files between and including "3" and "6" to be selected.
So we would have: xxxxx12xxxXxxxxxx789xxxx.
What actually happens, is different.
In the "Open file" -dialog (N.B. This is also how Konqueror's "Icon view" and "Multicolumn view" behave!):
- We can "Click" or "Ctrl+click" as we like, and this works as expected.
- When we "Shift+click", only the files between our _last two_ "Shift+clicks" are selected, and _selection is removed_ from all other files!
- We can continue our "Shift+click" travels in the dialog, and always instead of "expanding" the selection with "Shift+click", we only get the files between our two last clicks selected.
(N.B. These are also selected in a rectangular manner, see http://bugs.kde.org/show_bug.cgi?id=59228, but that is a different issue. This report is about files being removed from selection without the user's intent.)
In Konqueror (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 can't, however, "Shift+click" properly, as this is affected by what our _last selected file_ "X" was.
- This time the selection doesn't "travel", as "X" doesn't change.
- While we "Shift+click" on files, we will always have a _range of files_, with X being in one end of the range, and selection is _removed_ from all files outside this range.
I'll give another example, of how de-selecting files with "Shift+click" should work. We have the following arrangement:
xxxx123456xXxx7890xxxx
Now, if we "Shift+click" on "X", and then on "5", the files between and including "X" and "5" should get _de-selected_. (In other words, files 5 and 6 are not affected.) |
|
| 2008-07-08 18:43:44 |
Yuriy Kozlov |
kdebase: status |
New |
Confirmed |
|
| 2008-07-08 18:43:44 |
Yuriy Kozlov |
kdebase: importance |
Undecided |
Wishlist |
|
| 2008-09-23 12:10:46 |
Jonathan Thomas |
kde4libs: status |
Confirmed |
Triaged |
|
| 2008-09-23 12:10:46 |
Jonathan Thomas |
kde4libs: statusexplanation |
The shift click behavior is improved a bit in KDE 4's dolphin and open file dialogs, but it's still not quite the desired behavior. |
|
|
| 2009-09-09 00:30:27 |
Bug Watch Updater |
kdebase: status |
New |
Invalid |
|
| 2009-09-16 23:50:54 |
Jonathan Thomas |
kde4libs (Ubuntu): status |
Triaged |
Invalid |
|
| 2010-10-18 18:14:28 |
Bug Watch Updater |
kdebase: status |
Invalid |
Unknown |
|
| 2011-02-04 12:37:19 |
Bug Watch Updater |
kdebase: importance |
Unknown |
Medium |
|
