On 10 Feb 2016 05:22, "Henrik Brautaset Aronsen" <[email protected]> wrote: > > On Tue, Feb 9, 2016 at 3:05 PM, Dirk Hohndel <[email protected]> wrote: >> >> On Tue, Feb 09, 2016 at 12:53:42PM +0000, JB2Cool wrote: >> > On 9 February 2016 at 12:48, Sebastian Kügler <[email protected]> wrote: >> > > > >> > > > A possible project I could mentor in the summer would be a mobile >> > > version of >> > > > the planner (if nobody vetos it). That would be a separate app from >> > > > subsurface-mobile but of course share a lot of code. >> >> This is open source. No one can veto what you want to do. >> >> > So don't implement the dive planning into the subsurface-mobile just yet >> > but does this really justify the creation of another companion app to >> > perform the dive planning? That'll then be 3 mobile subsurface apps we >> > have, surely better to restrict the number of them and eventually (Even if >> > it's a while out) merge the functionality into a single app. >> >> The companion app goes away. Subsurface-mobile replaces that (even though >> that part of the functionality definitely needs a lot more testing). But >> no, this would get us Subsurface-mobile and Subsurface-planner. >> >> And while I would hate to see people spend time on the latter I can't stop >> you. My guess is that Sebastian and I won't be contributing there, so >> you'll be a bit on your own for now, but that's how it goes if you want to >> do something that isn't really useful for the goals of the project (as >> laid out by the humble maintainer). > > > A separate Subsurface-planner would be nice as well. Maybe something simple, with just table based input and output, utilizing the powerful deco planner core that we have.
I created the basics of a table input/output planner ui. I haven't submitted it as I really didn't want to distract from getting the first mobile release out, and also I haven't had time to work out how to connect it to the core code (which requires me learning qt and c++). I keep changing my mind whether the better option is modify the existing c++ models to suit qml (and still work for the desktop), or duplicate the models. Maybe someone else could sort that out quickly. I think it'd be a lot simpler than the existing dive list code. I'll submit the code *FOR DISCUSSION* when I get a chance. Perhaps tonight au time. It fits into the current mobile app. It could be standalone, but I don't see the point, and then it would lose the potential to plan based on gas loading from real dives. > Many would appreciate an open source alternative to expensive and slightly awkward software like Multideco and Baltic deco planner. > I agree completely. Plus my buddy's version of MultiDeco on his phone has started giving odd results and I don't trust it. Rick
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
