Bug 86756

Summary:	klistview::selectedItems() returns hidden items
Product:	[Unmaintained] kdelibs	Reporter:	Sebastian Sauer <mail>
Component:	general	Assignee:	Stephan Kulow <coolo>
Status:	CLOSED INTENTIONAL
Severity:	normal
Priority:	VHI
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Patch

Description Sebastian Sauer 2004-08-07 16:32:38 UTC

Version:            (using KDE KDE 3.2.3)
Installed from:    Debian testing/unstable Packages
Compiler:          gcc (GCC) 3.3.4 (Debian 1:3.3.4-3) 
OS:                Linux

Calling KListView->selectedItems() could return items that are selected but hidden. If a devel choosed to hide items they shouldn't be accessible normaly. It's strange to still return them on asking for the selectedItems() cause even the user could not know/see what he selected. That's why I call this a strange bug that need to be fixed.

The reason seems to be in klistview.cpp line 1202. 
QListViewItemIterator it(const_cast<KListView *>(this), QListViewItemIterator::Selected);
needs to be
QListViewItemIterator it(const_cast<KListView *>(this), QListViewItemIterator::Selected|QListViewItemIterator::Visible);
I would say/assume.

Comment 1 Sebastian Sauer 2004-08-07 17:05:34 UTC

Created attachment 7031 [details]
Patch

Cause the patch I mentioned above seems to work at least for kmldonkey I
attached the fix as patch (I'm still not sure if I got it managed to produce a
correct patchfile cause I normaly work in the cvs only :-).

Comment 2 Sebastian Sauer 2004-08-15 18:29:49 UTC

Maybe I should add some more description to get some more attention here;

Let's assume your listview have item1, item2 and item3.
item2 is hidden(), cause the listview is sorted those item2 is between item1 and item3.
now select item1, pull down the shift-key and select item3.
the user would expect two items are selected (item1 and item3), but that's false. item2 is selected as well! 
well, the user isn't able to see item2 nor that item2 is selected...
let's assume those klistview implemenents a contextmenu with actions like "delete selected items" and the developer just iterates over  klistview->selectedItems() and deletes each item. uh, how funny that item2 got deleted as well then...

Maybe it's only my understanding of what a "very high priority" bug could be, but I guess this one is definitivly very dangerous! Therefore I changed the priority to very high in the hope someone agrees or at least says I did something totaly wrong on my work with klistview's. Thanks.

Comment 3 Sebastian Sauer 2004-09-14 00:52:54 UTC

Thanks to Aaron Seigo for the feedback re this bug.

He clarified that this behaviour is wanted cause developers may have to get selected but hidden items as well. Also it is somewhat consistant to Qt where selected items are still selected if the are hidden.
Also if this a odd behaviour from my point of view, this bug is marked as WONTFIX till someone complains (or write some hints at the KListView-documentation about this behaviour :)

Comment 4 Sebastian Sauer 2004-09-17 14:29:12 UTC

Finally this bug got fixed by Aaron, thanks. http://cia.navi.cx/stats/project/kde/kdelibs/kdeui/.message/2555372

Comment 5 Scott Wheeler 2004-10-09 07:30:28 UTC

Just reading back through some of my old mail -- if you want more fine grained behavior you can build up a list of items using a QListViewItemIterator with a set of flags or-ed together to get just the set of visible and selected items.