I can reproduce that behavior.
It seems the larger amount of items in a folder, the more time it takes to deselect when click on a filename. Instead, deselecting by click on any other column, as well as with Ctrl+Shift+a is instantaneous.
Thunar 1.8.14
I realized something else... With each new deselection, the memory of Thunar's process grows gradually and remains high. The only way to get around this eventually is to kill this process.
Thank you very much. I tested Thunar (built from source) with the patch on a virtual machine, where the problem also happened, and this, apparently, solved the memory leak and slowness in deselection. Awesome!
I didn't notice any side effects, but I believe it needs a longer and deeper test, right?
Furthermore, the (or another) buggy behavior can be triggered when you have single click enabled and just hover over the files which are mentioned in the test case.
Thank you both for testing ! And finding that regression .. meh.
If you have time, please feel free to work on a proper patch. Since this one seems to require more investigation work, I will first finish some other stuff.
Exo-tree-view has two code parts which restore the previous row selection by reselecting them one by one, and the result is that thunar_standard_view_selection_changed is called over and over again.
Thanks, think I finally got it .. I just did not realize that deselection per default happens automatically.
Let me sum it up (Please correct me if I am wrong):
gtk_tree_view_set_cursor will automatically wipeout our current selection, if some file is clicked (or hovered on single click mode) (e.g. while holding STRG)
The old way of fixing that "whipeout" was, to just re-select all the files in a loop which were whiped out.
Your fix removes that loop, and prevents the "whipeout" instead, by temporarily disabling the selection updates for the current selection.
Maybe changing the comments a bit would make it more clear for the next readers:
Old:
/* disable selection updates if the path is still selected */
New:
/* Per default the current selection would be cleared */
/* Disable selection updates in order to keep our current selection if 'path' is still selected */
Hmm, ok ... so we as well could use g_signal_handlers_block_by_func ? Though not sure if there is a selection_changed function on exo level we could block with it (in case it has any advantages over gtk_tree_selection_set_select_function at all)
You only provided a diff, not patch/MR, so I assume you are not yet finished with your fix / you are not sure if it is the correct way to go ?
I had that fix installed now for a month, so far no side effects.
g_signal_handlers_block_by_func seems to be no option here, since the handling of the signal is done by GtkTreeView, not by us, so I guess your approach is good to go.
Just took another review on the code, and I think we can further simplify:
That old if-block which initially sets the select function to exo_noop_false if nothing was set so far seems not to be needed any more. (We currently set exo_noop_false every time on the same condition)
So I dumped it and re-used it's comment, which is anyhow better that my old proposal. (attached a patch with the changes)
I tested thunar list view (with directory specific settings disabled because of thunar#388 (moved)):
move single file
move multiple files
select single file in selection if multiple are selected
select single file outside selection if multiple are selected