aboutsummaryrefslogtreecommitdiffstats
path: root/device.c
AgeCommit message (Collapse)Author
2014-01-16Whitespace and coding style updatesGravatar Dirk Hohndel
Another futile attempt to cleanup the code and make coding style and whitespace consistent. I tried to add a file that describes the key points of our coding style. I have no illusions that this will help the least bit... This commit should ONLY change whitespace Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2014-01-08Change fake profile behaviorGravatar Dirk Hohndel
If no average depth is known the current fake profile behavior is rather unintuitive (we make up an average depth). Instead we should assume that this is a PADI style dive log and give the user a "rectangular" profile (actually, it's a trapecoid as we at least try to enforce a sane ascent / descent speed). If the dive is somewhat longer or deeper (10 min / 10 m) we even add a 3m safety stop at 5m. Added a new dives/test0b that tries to capture the typical cases to test this. Fixes #398 Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-11-12Make fake profile average depth come out rightGravatar Linus Torvalds
This isn't perfect as it doesn't really cover all cases. If we need to generate a profile for some fairly insane cases, the stupid thing just gives up rather than try to search for a solution that satisfies the constraints. For example, if you have a maxdepth=10m and an average depth of 9.9m, it will try two different (roughly sane) dive profiles, fail to get anything that matches that kind of dive and that average depth, and then just say "screw it, I'll match an insane profile instead" and basically generate a rectangular dive. It does seem to handle the few cases I tried. Somebody should double-check my math, and I think we might want to make the "default profiles" a bit saner. Right now the preferred default profile simply says "ascent/descent rate of 5m/min, with two levels at max_depth and 1/3rd maxdepth". That profile might not work for the simple reason that maybe we did a quick dive to 40m, but then came up and spent a lot of time in shallower waters, so our average depth was just 10m or so. Obviously we can *not* make a dive that has the two depths 40m and 13m come out to an average of 10m deep. So it has a fallback for things like that, where we try to generate a profile with a faster ascent/descent rate, and a shallower second depth. And then there's the fallback with an insane 10m/s ascent/descent rate and a second depth that is basically at the surface, and if we can't generate a dive profile with those parameters, either my math is wrong, or somebody was playing with rockets under-water. So we just give up. There's a few other heuristics too (if there is no average depth, we create a random one just to make the profile look reasonable). I *think* this is all perfectly fine, but I do want others to take a look. It might be doing something stupid. [Dirk Hohndel: after the discussion I took the patch and reworded parts of the commit message] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-06-18Converting the device_info list into a Qt data structureGravatar Dirk Hohndel
This data structure was quite fragile and made 'undo' when editing rather hard to implement. So instead I decided to turn this into a QMultiMap which seemed like the ideal data structure for it. This map holds all the dive computer related data indexed by the model. As QMultiMap it allows multiple entries per key (model string) and disambiguates between them with the deviceId. This commit turned out much larger than I wanted. But I didn't manage to find a clean way to break it up and make the pieces make sense. So this brings back the Ok / Cancel button for the dive computer edit dialog. And it makes those two buttons actually do the right thing (which is what started this whole process). For this to work we simply copy the map to a working copy and do all edits on that one - and then copy that over the 'real' map when we accept the changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-06-17Merge branch '119_divecomputerManagement' of github.com:tcanabrava/subsurfaceGravatar Dirk Hohndel
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-06-10Moved the 'create fake dc' to it's own function in device.cGravatar Tomaz Canabrava
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
2013-06-07Added the code to remove a dive computer.Gravatar Tomaz Canabrava
Added the code to remove a dive computer, plus a few fixes Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
2013-02-03Sort the devices when adding them to the device listGravatar Linus Torvalds
This doesn't change any real semantics, but it means that we will write out the device computer information in a well-defined order, rather than in some random order (before this: reverse order of reading them in). Having the XML file be as stable as possible is important so that *real* changes stand out when you make changes to your dives. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-01-24Save all dive computer nicknames - whether used or notGravatar Linus Torvalds
We used to save dive computer information only if that dive computer was actually used in any of the dives we saved. But we can simplify the code if we just always save any dive computers we know about. And it does allow for some usage cases where you have nicknames for other peoples computers that you may not actively use, but you want to see if you end up loading multiple XML files in one go. So there's just no compelling reason to not just save all the info we have. And this will make it less painful to remove the "use system config for dive computer nicknames", because you can also use this to continue to gather dive computer info in a separate XML file if you want to. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-01-18Add facility to edit nicknames / remove nickname entryGravatar Amit Chaudhuri
This allows users to edit one or more nick name entries in a single session. Entries can also be removed individually. Based on mock up by Lubomir Ivanov and various conversations from Dirk. Thanks to both. [Dirk Hohndel: quite a bit of editing for coding style and whitespace] Signed-off-by: Amit Chaudhuri <amit.k.chaudhuri@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-01-09Move device_info handling into a new 'device.c' fileGravatar Linus Torvalds
The legacy nickname wrappers (that use the device_info structure) are left in gtk-gui.c. We can slowly start moving away from them, we don't want to start exporting that thing as some kind of generic interface. This isn't a pure code movement - because we leave the legacy interfaces alone, there are a few new interfaces in device.c (like "create a new device_info entry") that were embedded into the legacy "create nickname" code, and needed to be abstracted out. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>