Re: Fwd: RFC: Statistics in Subsurface

[Berthold Stoeger via subsurface]

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

Re: Fwd: RFC: Statistics in Subsurface

[Willem Ferguson via subsurface]

On 2020/05/08 17:42, Dirk Hohndel wrote:


So let's go back to what I said earlier about (ab-)using the filter. 
How about we use the insanely flexible filter to allow the user to 
define their own group:

- pick filter settings (dive with tag 'boat', longer than 40min)
- name that 'set' (boat dives > 40min)
- pick different filter settings (dive with tag 'boat', 30-39:59 duration)
- name that 'set'
combine a group of 'sets' into a group which gives you the slicing of 
the dives that you want


Now offer those sets as rows in the statistics table. That way we can 
reasonably easily allow users to create almost any statistics they 
might want.



/D

So what this would amount to are two different initiatives which could, 
potentially, run in parallel.


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. This table would now have slightly a different 
function, i.e. to store the output of the filter process. It might 
possibly not be directly displayed any more but be accessed through the 
Statistics facility.


2) Rendering statistics in a panel. For the moment, let us assume the 
current (yearly-statistics) table is used to store the results of the 
filtering. I cannot see why not since the table is easily extensible. So 
this second activity would include reading the information from the 
(yearly-statistics) table and presenting it in the statistics panel. 
This would be a QML implementation.


As for activity 1) above, There would need to be some UI components to 
manipulate filter 'sets".


A button to add (=store) a set after it has been defined/edited in the 
filter panel.


A dropdown box indicating the sets that have been defined. The sets 
would probably just be defined as "Filter1", "Filter2", etc. Clicking on 
a specific set in the dropdown box allows editing or deleting a set.


A button to clear all sets. Although the yellow-arrow button to "Reset 
filters" could perform this function.


BUT: would this mean that the existing filter panel be rewritten in QML 
to be mobile-compatible? For mobile, would this be a scaled down version 
or a full-blown version?


Kind regards,

willem





--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface