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
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
