Patch and task

Robert Helling helling at lmu.de
Mon Mar 31 05:34:56 PDT 2014


On 30.03.2014, at 20:56, Lakshman <acrlakshman at gmail.com> wrote:

Lakshman,

> On Wed, Mar 12, 2014 at 10:55 AM, Robert Helling <helling at lmu.de> wrote:
>> Hi,
>> 
>> here is a a patch that enables the use of the “entered” field in divedatapoint. (It also reenables the planner, so Dirk before applying you may want to remove the change to main window.cpp). The goal is, eventually, in the planner, to also show the calculated waypoints for deco stops. So far, the calculated deco is only output via qDebug() to the console.
>> 
>> Maybe this is a nice task for a GSoC applicant to show some programming skills to make this info actually go to the UI (either in the existing table or in a third table).
>> 
> Hello Robert, I think attached patch does what we need. Snapshot is
> also attached. Commit message has few TODO things that I am working on
> currently.

thanks a lot. Indeed, this seems to work even though that UI has several rough edges.

> This patch was built on the current "master" branch and it includes
> the patch you sent to the mailing list which enables "entered" field
> in divedatapoint.

Could you resend it not including my patch, i.e. relative to my patch. Not only you are passing code that I wrote as yours but the two are logically independent and we might decide to use just one and not both.

I have to admit that I am completely hooked on the “two tables” idea. We might end up deciding that this is a good way to present things but the fact that we can’t get the other to work is not a good excuse.

I was going to ask Tomaz (and of course everybody else) who has a better understanding of this signal/slot business for help. I might as well do it here.

Let me remind you that we are working on the planner and I set the task to display the computed waypoints (i.e. the deco stops) not only in the plot but in the table as well.

In the current version, the deco is computed in the plotting function. It would seem simple to add the corresponding deco segments to the model after they have been computed. The problem is that adding the segments triggers the data changed signal of the model with then makes the plot replot which recalculates deco which then tries to add the additional stops and we have an infinite loop (or infinite recursion if you prefer that). The idea towards a solution was to somehow pass the information that the deco does not have to be recomputed when adding the deco segments. But at least to me it is unclear how to pass that information since the call is not explicit but via a triggered signal. Is there any way to pass a (boolean) flag along with a data change signal? How is that supposed to be implemented? 

Note well that a variable (either in the model object or the plot or anything else effectively global to the planner) is not a solution as there might be other triggers (for example originating from a mouse click) of the data changed signal while we are trying to add the deco stops and that other trigger should of course make the deco be recalculated.

Best
Robert

PS: If we proceed with two tables I guess the next thing would be to combine the two segments with a common end depth, i.e. the transition to the depth and the actual stop, into one combined table row only displaying the sum of the two times. The transition (at standard speed) would always be implicit. Furthermore, for deco stops two times should be displayed: the actual duration of the stop (including the time of the ascend to it) as well as the total run time of the dive until leaving the stop depth. Currently you are showing the latter but the table header claims it is the first.

-- 
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140331/00be6424/attachment.sig>


More information about the subsurface mailing list