[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 142791] "Shift+click" _de-selects_ files in Konqueror
From:       ko69859 () uta ! fi
Date:       2007-03-13 14:53:11
Message-ID: 20070313145311.15014.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=142791         




------- Additional Comments From ko69859 uta fi  2007-03-13 15:53 -------
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.


[prev in list] [next in list] [prev in thread] [next in thread]