bug #86756: klistview::selectedItems() returns hidden items

[Jason Keirstead]

> I guess it's a good behaviour to don't deselect them if they are hidden cause
> it make sense to still have the previous selected items still selected if
> they are shown again. That way it's easy to implementate a kind of filter
> which just hids the items that doesn't match the filterrule. If the
> filterrule changes they are still selected without just one line of code.

I don't know about this. To me it seems counter-intuitive. How can an
item be "selected" if it is hidden? The user can't select an item that
they didn't see.

To me, if  filter rule was applied the developer should be
de-selecting all the items anyway, to force the user to validate the
selection.

Imagine:
   User is looking at a list of all files
   They select some to copy to the clipboard, paste in another window
   The user applies a filter (*.jpg)
   They sholt shift and click the bottom element to select all, they
then delete.

In this case if the selected items are not de-selected when they are
hidden, they will get deleted along with the JPG images, which is
surely not what the user wanted.

In fact, I cannot really think of a case where it would be usefull to
the user to maintain selections across applying filter rules. After
applying any filter, the user would surely only expect any operations
they perform to be acting on what they *see*, and nothing more.

So really, in what situation would this API be usefull at al? To me it
looks like a simple oversight.

--
There are two major products that came out of Berkeley: LSD and UNIX.
We do not believe this to be a coincidence.  ~Jeremy S. Anderson