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
<willemfergu...@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.
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface