Filter games by save status and/or platform

[kekonn]

What's your idea?

I propose two new filters:

• Save status: new, updated, no filter
• Platform: Based on the list in Roots, i.e.: show only steam games, ...

[kekonn]

One filter is done, but I am currently investigating how to get the information of what root the game belongs to, in the game list.

[mtkennerly]

For the root type filter:

• In scan::scan_game_for_backup, when we add a path found by scan::parse_paths, we can track the root type the same way that we currently track whether the path is case-sensitive. Then, when we find a path that exists, we can keep a set of all unique root types with a match and store that as part of the returned ScanInfo.
• search::FilterComponent::qualifies would then be able to access that new field from ScanInfo.

We could even store the root type as part of each individual ScannedFile, but we're only filtering at the game level right now, so I don't think that's necessary. We could also consider putting a badge in game_list::GameList for the root types, if there's room for it.

[kekonn]

For the root type filter:

• In scan::scan_game_for_backup, when we add a path found by scan::parse_paths, we can track the root type the same way that we currently track whether the path is case-sensitive. Then, when we find a path that exists, we can keep a set of all unique root types with a match and store that as part of the returned ScanInfo.

It's been a while, but I'm trying to pick this up again and as I'm going through scan_game_for_backup I notice that it would technically be possible for a single ScanInfo to contain files from multiple roots and thus stores, right?

So the only real way to do this would be to set the store type on the ScannedFile struct and filter through those in the filter.

This would mean the filter would go through all the files and leave the ScannedConfig in if any of the files matched the selected store.

Do you agree with this behaviour?

EDIT: I've put the above mentioned behaviour in the linked PR, ready to accept if you agree.

[mtkennerly]

Based on the discussion in #329, I think the underlying use case is now addressed by #44, but please let me know if you have any other ideas or issues related to this.