filtering: stages of expansion

[sebastianelsner]

There are several stages we can improve on filtering table/tree views:

1. use a basic QSortFilterProxy model to filter one or all columns at once using a QLineEdit to enter arbitrary search terms.
   Advantage: easy to implement (already there), Disadvantage: does not allow to specify more complex filters like "all my done jobs", no selective multi column filtering only one ro all columns
2. A slightly improved version allows to set the column or either all columns to be filtered in
3. use QSortFilterProxyModel with regexes to allow regexes like [Unknown|Idle]. This is not very intuitive to the end user, but provides a quick to implement way of getting better filter results.
4. provide a way to save search strings as presets and display them as buttons, so we do not have to implement specific filters like " [x] Done [x] Unknown " etc. This could make the system very flexible
5. Use an easy to learn syntax for specifying filter queries: "Status:Idle AND RAM:>=64". Parsing this could be borrowed from the "whoosh" search library. This would allow for very flexible filters and nice presets, but would need a custom (i.e. python, which could mean slow) implementation in the QSortFilterProxy model.

[samson-jerome]

I think either (1) or (4) solution would be better:

• (1) simple "all columns" filter is a good start as we mostly request on "user", "name", "prod".
  It can be a bit tricky for "status" as user doesn't know the int value of each status.
• (4) predefined filters is attractive as it can easily be configurable, we can imagine having custom filters saved per users in addition to more generic filters accessible to everyone.

[sebastianelsner]

(1) is basically there. Status is easy and works, since filtering in general is using the "DisplayRole" which is the "nice" display name for a status.
(4) this shoud be the ultimate goal, I agree