planner tank handling

Dirk Hohndel dirk at hohndel.org
Thu May 29 12:27:38 PDT 2014


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.

/D


More information about the subsurface mailing list