Selected files and folders are not deselected when filtered out

[jpovixwm]

When searching in the file tree, I expect entries that were previously selected, but are now not displayed due to the filter, to be deselected. Similar behavior is already implemented in the main torrents table. As a point of reference, qBittorrent's file tree does deselect entries that go out of view when filtering. Additionally, I believe hitting Ctrl-A when search keywords are present should only select the entries that are visible.

I can contribute a fix to these problems, but to avoid the risk of wasting effort, I'm opening an issue first to gather feedback.

[qu1ck]

Both are valid points, fixes are welcome.

[jpovixwm]

Ok, so this turns out to be more complex/nuanced than I initially anticipated. I'm not sure what behavior would give the best UX in this component.

Some things that I've encountered:

• It is possible for a directory to have some descendant entries that are selected, while the directory itself is not selected. In such case, there's no visual indication on the directory entry that would tell the user that some descendants are selected. This is especially annoying if the directory entry is collapsed. I experimented with marking such directories using a gray background:

  But I'm not entirely satisfied with the look and feel.

• It's possible to have a directory that is itself selected, but some of its descendants are deselected:

  When executing an action against a selection like this, the action will apply to the PNG files as well, because their parent directory is selected:

  

  So it seems like being able to deselect descendants of a directory which itself is selected is meaningless, as it doesn't achieve anything. Would it be a good idea to automatically deselect all ancestors of an entry when an entry is deselected? Like this:

  
• When a filter is applied, should Ctrl-A only select the visible file entries, or should it select the directories as well? For example, with a filter like this:

  If Ctrl-A were to select all visible entries indiscriminately, the user would end up with a selection like this, even though they were looking specifically for PNG files:

  

  But if Ctrl-A would only apply to visible files, the result would instead be this:

  

  On the other hand, Ctrl-A is supposed to mean "select all", so maybe this is fine? If the .png filter is applied again afterwards, should the .jpg files become deselected, as they don't match the filter? If so, we arrive at the first bullet point again. Even if the .jpg files were automatically deselected, they would still be effectively selected because the Images directory is still visible with the filter applied, so it wouldn't get deselected. Alternatively, the deselect-on-filter behavior could be made so that it doesn't deselect entries that have a visible & selected ancestor, in this case the Images directory. Something like this:

  
• As currently implemented on the master branch, deselecting a directory automatically deselects all of its descendants. I have mixed feelings about this behavior. I think most of the time I don't want the descendants to be deselected when I deselect a directory (such as in the last GIF), but when I select a directory, selecting all of its descendants appears to make sense, due to bullet point #2 However, this would have the consequence that once you select a directory (done with a single click), you will have no equally easy way of undoing this, because the descendants would remain selected. A potential solution to this problem would be to make the behavior conditional: When deselecting a directory, deselect its descendants only if all of its descendants are selected; otherwise, don't touch the descendants. But I can already see how confusing this could get for the user.

Please let me know what's your opinion on all this.

[qu1ck]

Yeah, there are many hidden gotchas in this.

It is possible for a directory to have some descendant entries that are selected, while the directory itself is not selected. In such case, there's no visual indication on the directory entry that would tell the user that some descendants are selected. This is especially annoying if the directory entry is collapsed. I experimented with marking such directories using a gray background:

I like this but make the background blueish gray or have blue inset shadow to indicate that this is related to selection, just to be more intuitive.

...So it seems like being able to deselect descendants of a directory which itself is selected is meaningless, as it doesn't achieve anything. Would it be a good idea to automatically deselect all ancestors of an entry when an entry is deselected?

Yes

When a filter is applied, should Ctrl-A only select the visible file entries, or should it select the directories as well?

Ideally it should select the directory if the directory itself matches the query, otherwise it should only select files.

As currently implemented on the master branch, deselecting a directory automatically deselects all of its descendants...

This one is important to keep, after all directories are just shortcuts to do operations on files contained within. Without a way to deselect folder and it's descendants it would be impossible to handle large directories.

In general I think it's more useful to think what kind of typical user operations are currently hard to perform that we want to improve instead of trying to capture how things "should" intuitively work. For example somewhat common operation would be to find all files of specific type scattered among folders and mark only those as (un)wanted or high/low priority. Therefore it makes sense for ctrl-A to select those but not folders that contain them, unless they themselves also match the query.

There is one more issue here (that exists even in current implementation) that is not covered above. The behavior of selecting a folder automatically selecting it's descendants makes it impossible to use "Open" and "Open folder" menu items on folders. It happens because those items are disabled when multiple rows are selected.

Some programs handle this by not visually marking selected descendants of folder when it is selected and simply implying the selection when actual action is performed (like changing priority or wanted status). In other words, when clicking a folder only the folder row is visually selected but when changing it's priority all descendants are changed anyway. This approach also makes sense to me. Another way to tackle the "Open" menu item issue is to make it act on the row that was last clicked (as opposed to selected) and therefore not be dependent on only 1 row being selected.

You don't have to fix this last one in the context of this issue, just bringing it up to see if you maybe have any arguments against changing selected folder logic to not visually select descendants because that will have implications on some of the points above.