planner tank handling

[Tomaz Canabrava]

On Thu, May 29, 2014 at 4:33 PM, Tomaz Canabrava <tcanabrava at kde.org> wrote:
> 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.

It's not.
DivePlannerPointsModel.cpp :

createTemporaryPlan()
createPlan();
tankInUse();
addStop()
addGas()
setupCylinders()
loadFromDive();

I can't create a planned dive just by using the C methods that exists
right now because we are dependent of those methods on the Model.

struct dive *dive = alloc_dive();
struct diveplan *plan = plan_start_from_dive(dive);
plan_add_gas();
plan_add_stop(plan, (M_OR_FT(15, 45), 1 * 60, o2, he, 0, true));
plan_run_algorithm(plan, algorithm-func-pointer);
plan_cancel(); // cleanup internals of the structures
plan_accept(); // cleanup internals of the structures.

all of those would be connected to the model ( or called by )

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