RFC: Statistics in Subsurface

[Dirk Hohndel]

> On Sep 27, 2020, at 7:21 AM, Willem Ferguson via subsurface <subsurface at subsurface-divelog.org> wrote:
> I think there is some misunderstanding, or am I myself misunderstanding?? See inline below.

I think I misunderstood you.

>>> 
>>> 1) UI for selecting variables to be plotted. At this stage just two comboxes as discussed in previous emails during May this year. This could benefit from QML , but the UIs on desktop and mobile are likely to differ vastly. Therefore doing it in QML may not necessarily yield tangible benefits and one may just as well do it in C++ for the desktop. Comments?
>> The more I think about this, the less I think it makes sense for this to be in QML on the desktop. Yes, it will need a QML UI on mobile if we decide to allow editing on mobile - but part of the reason why we are storing those filters in the cloud storage is so that we don't need that UI on mobile in the first place. Because: painful, complex, error prone on a small touch screen
>> So I'm fine with what Berthold has started, just using QWidgets
> 
> I am talking about UI element(s) that allow selecting the variables one wants to graph. You appear to be talking about selecting dives to be analysed. In a typical situation one would use the filter to select all the dives at a particular dive site, or the dives during a particular year. After selecting the appropriate dives using the filter, one needs to, in addition, specify which variables on wishes to graph, e.g. SAC versus Depth. After using the filter, one ends up with a dive_table in which the filter has selected all the appropriate dives using the dive->selected boolean. Now one needs to define the plot variables. So this is a SECOND level of selection AFTER filtering. In most cases variables used in filtering will NOT be involved in the drawing process: e.g. if one filtered for dives during 2019, it does not make sense to plot year because there are only dives for one year (2019).

Sorry, misunderstood you here.

So that seems like it could go either way. My inclination would be to try doing this with QML - since it is rather closely connected to the actual graphing... but I'm not 100% sure that's the right call here.

>>> 2) Background infrastructure for creating arrays/structures/linked-lists to be plotted. This interacts with the dive_table structure, extracts appropriate information, creates appropriate categories (e.g. when plotting values associated with tags). This should probably be in C++ since no UI is involved and I cannot see why QML would be beneficial. Is this point of view realistic?
>> Definitely. And I think Berthold is planning to write that code.
> I am not talking about the filter here. Let's say we wish to graph the number of dives for each month of the year. The dives in the dive_table needs to be scanned for month and the appropriate accumulators created to keep a tally of the number of dives for each month as one scans the dives that have been marked as dive->selected.  This is likely to be in C or C++, not QML. These calculations are independent of the filtering process that is likely to have happened beforehand.

That part I understood correctly - and IIRC Berthold offered his help in creating the model that you need in order to visualize data in QML. I'll have him speak up if I am wrong... but typically these models are exactly the type of things he enjoys fighting with :-)

>>> 3) The graphing that occurs within a single graphview object. This should probably be beneficial if it were written in QML, since it would be portable to the mobile environment. Porting this to mobile might mean rewriting the UI frame/page/tab to place the graph at an appropriate place, but the way the graph is constructed will be standard across desktop and mobile. Is this point of view realistic?
>> Yes - if we can use the same QML code on desktop and mobile for actually creating the graphs, that would likely be best.
> As a side-comment, every time I get in contact with Berthold's filter code I am impressed with the longer-term vision. Only now do I realise why the filter sets actually need to be stored on the cloud.

Berthold scares me - in a good way.

/D