Would you mind mailing an example file that shows this behavior to me? hel...@atdotde.de Then I could have a look.
Best
Robert
On Jan 2, 2017, at 10:24 PM, Humberto Hassey <hha...@gmail.com> wrote:Hello, I am using Sub Surface 4.5.6 on Debian. On my log book my dives show the tissue saturation graph but only for the first dive of the day, on second or more no graph shows. Is this normal or a bug?
--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/91cd36fd-27cb-4bdf-819f-640a8018580a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<merged diving day 2017-01-04.PNG><unmerged dive.PNG>
Robert, my guess is this stems from the way we pick the deepest spot during thedive and where VPM-B starts calculating the deco for the ascent? Or is thereanother explanation why the surface interval doesn't appear to desat the diverat all?
For more options, visit https://groups.google.com/d/optout.
<merged diving day 2017-01-04.PNG><unmerged dive.PNG>
On 05 Jan 2017, at 16:26, 'Robert C. Helling' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:What worries me, is that for me (who has set deco mode by default to Buehlmann), when opening the file with the two dives and merging them, I get ceilings on both. Then I switch to VPM-B I get what you describe and then I switch back to Buehlmann the ceiling on dive two disappears. This should not happen. I will investigate this.
On 05 Jan 2017, at 16:43, Robert Helling <hel...@atdotde.de> wrote:a little bit of further debugging showed that in SettingsObjectWrapper::load() prefs.deco_mode gets a value 2 at startup. I have no clue why that is the case. My preferences („Buehlmann“) should get save but apparently aren’t. But I also have no clue how this SettingsObjectWrapper things is supposed to behave, so…PAGING Tomaz….
On 05 Jan 2017, at 16:48, Robert Helling <hel...@atdotde.de> wrote:or to be more specific: It seems to me that SettingsObjectWrapper::sync() never gets called. And the reason for that might be that there is no call for it anywhere in the code…
On Jan 5, 2017, at 8:00 AM, Robert Helling <hel...@atdotde.de> wrote:Hi,On 05 Jan 2017, at 16:48, Robert Helling <hel...@atdotde.de> wrote:or to be more specific: It seems to me that SettingsObjectWrapper::sync() never gets called. And the reason for that might be that there is no call for it anywhere in the code…and there is another problem: There seems to be a total confusion betweenprefs.deco_modeandprefs.display_deco_mode.The current state is utter non-sense. Tomas, (according to git blame you introduced the latter) could you please explain the meaning of the two and in particular their difference?Here is my guess: There are two, because one is set in the preferences while the other is a planner parameter. They do the same thing but when chaining the value in the planner, the display of logged dives should not be affected.
So my suggestion would be to resolve this as follows: Rename deco_mode to planner_deco_mode. In all the code, when we need to inquire the current deco mode, we replace the access to the value by a getter that essentially doescurrentState == PLAN ? prefs.planner_deco_mode : prefs.display_deco_mode;What do you think?
--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/57EF1A4A-0883-4475-9E84-0618CA72EBAF%40hohndel.org.
On 05 Jan 2017, at 21:04, Tomaz Canabrava <tcana...@kde.org> wrote:Robert, the difference on the preferences for deco mode is what you described - one is for the planner and other is for the display. I tougth id fixed the issue you described to me in your house - and I think I did, but in the end I created another issue. The getter idea seems correct, sorry for the confusion.
ProfileWidget2 *view = qobject_cast<ProfileWidget2*>(scene()->views().first());
view->currentState == ProfileWidget2::PLAN
Btw - sync and load are being called because your preferences are saved and restored :)
On Jan 5, 2017, at 1:57 PM, Robert Helling <hel...@atdotde.de> wrote:Hi,On 05 Jan 2017, at 21:04, Tomaz Canabrava <tcana...@kde.org> wrote:Robert, the difference on the preferences for deco mode is what you described - one is for the planner and other is for the display. I tougth id fixed the issue you described to me in your house - and I think I did, but in the end I created another issue. The getter idea seems correct, sorry for the confusion.Before I start coding, I have a question (which shows how little C++ I understand): What exactly doesProfileWidget2 *view = qobject_cast<ProfileWidget2*>(scene()->views().first());(this is line 266 of divetooltipitem.cpp)?How much overhead does this have? I hope, it does not create and initialise a whole ProfileWidget2, because all we need to do is