Patch and task

[Lakshman]

On Mon, Mar 31, 2014 at 7:34 AM, Robert Helling <helling at lmu.de> wrote:
>
>> 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.
>
Yes, there are some rough edges, few of them are listed in TODO of the
commit message (first three are directly related to the new table),
which I am currently working on.

>> 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.
>
Updated patch is attached. I would like to mention that, I couldnot
directly your first patch
"0001-Distinguish-between-entered-and-calculated-waypoints.patch" onto
the current master, hence I wrote its content manually and wrote new
patch relative to it. I would have rebased my old branch with your
patch applied long back, but unfortunately I deleted that branch,
hence I had to go through this. Ofcourse there may be still some ways,
but I am not familiar with using git yet.

> 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.
>
Two tables thing is what I have been thinking, I never thought about
extending existing table, until I saw your "entered" branch Yesterday.
Then I tried make a quick hack and couldn't complete it, yes I am not
good with Qt yet.

> 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.
>
Yes Robert, I remember.

> 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?
>
I get your point completely, but I cannot comment on this until I give
sometime for this, and will get back to this. However, to get around
this, I introduced a variable "emitPointEdit", as a quick hack,
without realizing the consequences. I will get back to this discussion
soon.

> 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.
>
Yes Robert, that was a blind hack, done in about half-hour, I will
think on this and work towards a cleaner approach. (If we decide on 2
tables, we need not worry about this, but for my understanding, I
should work on this to familiarize with some concepts).

> 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.
>
Yes, will work on this and update accordingly.

Thank you,
Lakshman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Diveplan-with-entered-and-computed-waypoints-to-UI.patch
Type: text/x-patch
Size: 9578 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140331/a5d4a182/attachment.bin>