RFC: Statistics in Subsurface

[Dirk Hohndel]

> On May 11, 2020, at 1:49 PM, Berthold Stoeger <bstoeger at mail.tuwien.ac.at> wrote:
> 
> 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).

(oh how I know THAT feeling)

> 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.

It could easily be versioned.
The nice thing about putting them into cloud storage is of course that you can
deal with the desktop UI to create them and use them on mobile. Given that I
generally hate mobile UIs (definitely including ours - but far more generally so),
anything that I don't need to create on mobile is a huge plus.

But what you are certainly correct about is that this would have to be designed
in a smart way. And of course, at this point the options available for filtering on
mobile are extremely limited, compared to desktop. If we want to go down this
rabbit hole, then... oh look, there is the next questions...

>> 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.

You are correct. It isn't necessary.
But at the same time, assuming we want to go down this rabbit hole of using
this as a way to define groupings in statistics, then yes, we most likely want
the exact same options for filtering here and there. Which is easiest done by
sharing the same QML widget.

> 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).

I'm not sure what you are saying here. Are you suggesting that we should
not try to have the same statistics module for desktop and mobile?

/D