Advanced Filtering System

Issue #446 new
pingurus
created an issue

I would like to implement an advanced filtering system, which enables you to not only filter for text, but also for route/track lengths/elevations/speeds/activities, wpt elevations/timestamps, geocache hidden dates/difficulty/terrain/size/enabled/attributes.

Do you have any suggestions for the design of the filter or should I just start coding and show you the result?

Comments (5)

  1. kiozen

    Do you have any suggestions for the design of the filter or should I just start coding and show you the result? - LOL

    Do whatever you think is appropriate ;) Maybe a few words about the current filtering and why it is as it is:

    • Maintaining the filter code shouldn't become a PITA. If you start with a filter dialog to choose fields to search in and add some fancy search rules (or, and, xor, etc) You have to touch the code every time a new field or property is added. This is not what I want.
    • The average QMS user has no clue about defining search strings. The best is punching in some words as in Google. No +, no - and for sure no fancy regular expressions.

    The solution for those requirements was simply matching the text in the filter line with the text that is derived for item info. The most advanced is QString CGisItemTrk::getInfo(quint32 feature). The feature field is controlling the content of the text, e.g. if the description is truncated or not. In the case of a filter it has to be the full text.

    The same pattern applies to the database. But it get's more tricky as the database has to be updated if the information changes in the sense of new information fields are added to the item info.

  2. pingurus reporter

    and for sure no fancy regular expressions. - I agree 100%

    However, if there should be more than just the search for exact matches, I think it either has to be either a dialog or regex or a combination of both. I understand the drawbacks of both, but have no idea, what a better aproach would look like.

    Regex: Minimal coding, minimal user friendly Dialog: Maximal coding, maximal user friendly

  3. pingurus reporter

    I thought a bit and I think we could basically leave the search as it is, but add some keywords like "under","over","shorter than","longer than".

    If the user then enters "track shorter than 5km", we could do the search as it is now and then add all tracks where the number in the info after "Distance:" is smaller than 5. This would have the benefit that we only need the info, however we need to touch the filter code if the info keywords change.

    Also I'm not sure how well translating would work because of the different word order. This would be a non existent problem with a dialog.

  4. kiozen

    Should be ok if you use the tr() macro. Anyway if we introduce such stuff it must be documented with a help dialog containing examples and stuff.

  5. Log in to comment