planner tank handling

Tomaz Canabrava tcanabrava at kde.org
Thu May 29 12:33:28 PDT 2014


On Thu, May 29, 2014 at 4:27 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Thu, May 29, 2014 at 04:21:28PM -0300, Tomaz Canabrava wrote:
>> >
>> > indeed the problem is that the information is kept (at least in part)
>> > in several data structures (model (i.e. UI), struct dive, dive plan
>> > and in the deco part as well in a list of depth at which something
>> > happens). We should come up at least with a good decision which is the
>> > primary place that gets copied to the others. I have to admit I
>> > haven’t understood this model thing well enough to have an informed
>> > opinion if that is a good primary place as you seem to suggest.
>
> The model is for the UI, nothing else. I refuse to use the model for
> anything else. The problem with the data structures on the C side of the
> world is that we have too many different dive structures floating around,
> all involved in planning the dive. And of course the diveplan.
>
>> The code right now is a bit of mess. What we *should* do:
>>
>> - the model shouldn't change any datastructure, it should call a c -
>> function passing the data structure and the changed values.
>> - the view shouldn't change any datastructures, it should call a c -
>> function passing the data structure and the changed values.
>
> I'm not even sure that I can parse this. Yes, the UI shouldn't hold any
> code that is the actual planner code - but I think it makes sense to have
> the logic behind the interaction in the UI code.
>
>> right now, the *logic* of the planner is on planner.c /
>> diveplannerpointsmodel.cpp, should be moved to planner.c
>
> So you are saying "no logic of planning" in the cpp file. That is the case
> today. But there is still too much of the "setting up the data" magic
> happening in the UI part - and that is coming back to bite us.
>
>> the planner is an awesome place to test the unittests, I will start there. ;p
>
> It is. But right now there are serious design flaws - I see little point
> in testing what we have. I want to get to a point where the architecture
> and design of the planner is in a sane state and THEN start writing tests
> for the components.

True. I'm online on irc, since we both + atdtode are the ones doing
the planner mainly, wanna do a quick meeting there about that?

> /D


More information about the subsurface mailing list