On Sonntag, 10. Mai 2020 12:48:24 CEST Willem Ferguson via subsurface wrote: > 1) Adapt the existing filter mechanism to store filter 'sets' and then > apply them to the dive list. Mechanisms to store filter "sets" and > combine them to extract dive list information that is stored in the > yearly-statistics table.
Such presets should be rather easy to implement and are useful independently of statistics. I can prototype such a thing at the end of the week (the next few days I'll be busy with work-related things). There is one crucial design decision to make: Should these filter presets be saved to the log or only to the site-preferences? If we save them to the log, then the filter options that we support are more or less cast in stone, so this shouldn't be taken too lightly. > BUT: would this mean that the existing filter panel be rewritten in QML > to be mobile-compatible? This is not necessary. The filter code is generic and we only need a tiny display layer on top. Let's not introduce QML where not absolutely necessary. Generally, I wouldn't try to do the all-in-one solution. There are two kinds of statistics, which I would treat separately. Firstly, an overview over a defined set of dives with filter presets. Secondly, temporal progressions (e.g. development of SAC rate, grouped by day / week / month / year). Berthold _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
