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 _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
