On Thu, May 29, 2014 at 4:33 PM, Tomaz Canabrava <[email protected]> wrote: > On Thu, May 29, 2014 at 4:27 PM, Dirk Hohndel <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
