already helping a bit http://fpaste.org/K0wJ/

nah fpaste, bad idea:

- Gtk.TreeIter iter;
- if (!model.get_iter (out iter, path))
+ Gtk.TreeIter filter_iter, iter;
+
+ if (!model_filter.get_iter (out filter_iter, path))
return false;
+ model_filter.convert_iter_to_child_iter (out iter, filter_iter);

(In reply to comment #0)
> Changing CollectionView:get_selected_items to use model_filter instead of model
> is a step in the right direction imo, but then clearing the search entry while
> in selection mode makes the hidden selected box appear and be selected. Imo we
> should just clear the saved selection when there are any changes in the
> filtering. I couldn't find how to do that from a quick glance, so just logging
> that bug for now.

I am not sure it is a good idea. Instead, I would rather disable actions when there is an active search. We should check with designers. In general, it's bad idea to undo what the user did..

Created attachment 223508 [details] [review]
collection-view: convert from filter_model to model for selection

Created attachment 223509 [details] [review]
Remove dead code

Created attachment 223510 [details] [review]
Hide selectionbar when searchbar is active

Review of attachment 223508 [details] [review]:

I'm not sure what you are trying to address with this patch, but this does not help with what I described in this bug report, when going to selection mode after filtering out a selected entry, the topbar still shows "1 selected".

Review of attachment 223509 [details] [review]:

ACK

Review of attachment 223510 [details] [review]:

I'd rather have input from the designers before we do this.
This patch has a number of issues, it lets you go in selection mode when search is active, but hides the bottom bar which makes selection mode useless, if nothing is filtered but the search bar is shown, the bottom bar is still disabled (the search bar should probably go away after a while in such cases)

Review of attachment 223510 [details] [review]:

the selection bar is only shown if there are selected items, and we are not in search mode.

Review of attachment 223510 [details] [review]:

I've understood that, but there is no point in being able to select items if the selection bar is not present.

Review of attachment 223510 [details] [review]:

I think it is useful to be able to filter the result and select items, and get back to selection mode with selection bar. It's clearly less error prone than current behaviour.

Review of attachment 223510 [details] [review]:

I'd rather we get feedback from the design team before trying to be smart with the behaviour, imo the changes you suggest are not intuitive at all. Going from one weird behaviour to another behaviour which is weird in other ways, and then potentially changing it again after we get feedback from the design team  does not really seem worth it.

Attachment 223508 [details] pushed as f9664c9 - collection-view: convert from filter_model to model for selection
Attachment 223509 [details] pushed as 062e150 - Remove dead code

While it's still not super elegant, when we ran into this for Documents, we suggested to always show selected items regardless of the query (OR <selected>). For cases when this is undesirable (bigger selection, still need to add a few items with query), the checkbox next to the search entry allows to hide the selection and only match the query string.

https://raw.github.com/gnome-design-team/gnome-mockups/master/documents/selection-toolbar.png

(In reply to comment #15)
> While it's still not super elegant, when we ran into this for Documents, we
> suggested to always show selected items regardless of the query (OR
> <selected>). For cases when this is undesirable (bigger selection, still need
> to add a few items with query), the checkbox next to the search entry allows to
> hide the selection and only match the query string.
> 
> https://raw.github.com/gnome-design-team/gnome-mockups/master/documents/selection-toolbar.png

Ah nice! May I suggest that the results are sorted alphabetically, and not list the selected items first? (if they are already selected, it is likely that's not what we are looking for, but it's still important to show it's part of the current selection)

(In reply to comment #16)
> Ah nice! May I suggest that the results are sorted alphabetically, and not list
> the selected items first? (if they are already selected, it is likely that's
> not what we are looking for, but it's still important to show it's part of the
> current selection)

ah perhaps it is already sorted by time in the screenshot!

Is this still valid? I can't reproduce through the steps in the description.

Yes, though the steps changed as selection mode behaviour changed (selection no longer remembered when going in and out of selection mode)

Go to selection mode
Select an item
Do a search so that the item was selected is hidden (eg select a windows box,
and search for fedora
-> the topbar says '1 box selected', and clicking 'delete' removes the
invisible box

However, things are much less confusing this way, so it might be acceptable not to do anything. Comment #15 seems to suggest this needs to be improved.

Looking at comment#15, we'll need to add new UI if we want to fix this further. So moving to 3.9.

Well the selection is no longer remembered when you exit the selection mode so this can't be reproduced anymore.