Fwd: Re: RFC: Statistics in Subsurface

[Willem Ferguson]

On 2020/09/27 15:13, Dirk Hohndel wrote:



I think there is some misunderstanding, or am I myself 
misunderstanding?? See inline below.

> Hi Willem,
>
> adding the Subsurface developer list to this thread
>
>> On Sep 27, 2020, at 5:34 AM, Willem Ferguson 
>> <willemferguson at zoology.up.ac.za> wrote:
>>
>> A quick question about the use of C++ and QML in writing code for 
>> presenting graphs. In general, my leaning is towards QML simply 
>> because making anything mobile-friendly is a longer term investment, 
>> even though I hate QML. But there are at least four parts of the code 
>> that may benefit differently from QML:
>>
>> 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).

>> 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.
>
>> 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.
> Curious if others have strong feelings about this...
>
> /D



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