Re: new daily builds and preparing for Beta 1

[Robert C. Helling]

Dirk,

> Am 01.11.2014 um 00:12 schrieb Dirk Hohndel :
> 
> 
> The CCR / PSCR code clearly needs more work.
> 
> What's the status of the planner?

Sorry I have been so silent recently but some real world issues required my 
attention more urgently. But I should have a few hours in the next week for 
subsurface. 

Do here is what I expect: 

CCR logging (as far as ceilings go) should work with gas consumption disabled 
beyond anything that is dillutant use at depth independent rate. 

CCR planning should work as well but still without much UI support for bailout 
variants except "from here bailout OC). 

PSCR will not be exposed to users (except maybe as Easter egg like have pscr 
keyword to turn on pscr ceiling calculations for testing). 

That is my plan which is hopefully realistic. 

Best
Robert
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: PATCH: Remove code that zeroes oxygen-related data and temperatures

[Willem Ferguson]

On 01/11/2014 00:02, Dirk Hohndel wrote:

Git complains about a corrupt patch...

/D




A second try, it was my fault.


Remove code that zeroes out duplicate oxygen sensor and temperature values

Remove the code that changes all duplicate oxygen sensor, setpoint and
temperature values from a dive log to zero. One of the motivations is
that a zero setpoint value indicates an Open Circuit dive segment, not
Closed Circuit Rebreather. The code in dive.c is removed and the comments
for the corresponding restoration code that restores the last known values
into sensor or temperature with zero values is [fill_o2_values()
in profile.c] is changed to apply to the present situation.

Signed-off-by: willem ferguson 


>From b19039cfb6d55640cf097e45fb5a33b19fca25a4 Mon Sep 17 00:00:00 2001
From: willem ferguson 
Date: Sat, 1 Nov 2014 06:06:34 +0200
Subject: [PATCH 7/7] Remove code that zeroes out duplicate oxygen sensor and
 temperature values

Remove the code that changes all duplicate oxygen sensor, setpoint and
temperature values from a dive log to zero. One of the motivations is
that a zero setpoint value indicates an Open Circuit dive segment, not
Closed Circuit Rebreather. The code in dive.c is removed and the comments
for the corresponding restoration code that restores the last known values
into sensor or temperature with zero values is [fill_o2_values()
in profile.c] is changed to apply to the present situation.

Signed-off-by: willem ferguson 
---
 dive.c| 26 ++
 profile.c | 27 +++
 2 files changed, 13 insertions(+), 40 deletions(-)

diff --git a/dive.c b/dive.c
index 9f4df56..4320626 100644
--- a/dive.c
+++ b/dive.c
@@ -1098,15 +1098,14 @@ static void fixup_dc_events(struct divecomputer *dc)
 
 static void fixup_dive_dc(struct dive *dive, struct divecomputer *dc)
 {
-	int i, j, o2val;
+	int i, j;
 	double depthtime = 0;
 	int lasttime = 0;
 	int lastindex = -1;
 	int maxdepth = dc->maxdepth.mm;
 	int mintemp = 0;
 	int lastdepth = 0;
-	int lasto2val[3] = { 0, 0, 0 };
-	int lasttemp = 0, lastpressure = 0, lastdiluentpressure = 0;
+	int lastpressure = 0, lastdiluentpressure = 0;
 	int pressure_delta[MAX_CYLINDERS] = { INT_MAX, };
 	int first_cylinder;
 
@@ -1164,31 +1163,10 @@ static void fixup_dive_dc(struct dive *dive, struct divecomputer *dc)
 		fixup_pressure(dive, sample);
 
 		if (temp) {
-			/*
-			 * If we have consecutive identical
-			 * temperature readings, throw away
-			 * the redundant ones.
-			 */
-			if (lasttemp == temp)
-sample->temperature.mkelvin = 0;
-			else
-lasttemp = temp;
-
 			if (!mintemp || temp < mintemp)
 mintemp = temp;
 		}
 
-		// If there are consecutive identical O2 sensor readings, throw away the redundant ones.
-		for (j = 0; j < dc->no_o2sensors; j++) { // for CCR oxygen sensor data:
-			o2val = sample->o2sensor[j].mbar;
-			if (o2val) {
-if (lasto2val[j] == o2val)
-	sample->o2sensor[j].mbar = 0;
-else
-	lasto2val[j] = o2val;
-			}
-		}
-
 		update_min_max_temperatures(dive, sample->temperature);
 
 		depthtime += (time - lasttime) * (lastdepth + depth) / 2;
diff --git a/profile.c b/profile.c
index 4bc9422..4be3a5b 100644
--- a/profile.c
+++ b/profile.c
@@ -928,31 +928,26 @@ static void calculate_gas_information_new(struct dive *dive, struct plot_info *p
 }
 
 void fill_o2_values(struct divecomputer *dc, struct plot_info *pi, struct dive *dive)
-/* For CCR:
- * In the samples from each dive computer, any duplicate values for the
- * oxygen sensors were removed (i.e. set to 0) in order to conserve
- * storage space (see function fixup_dive_dc). But for drawing the profile
- * a complete series of valid o2 pressure values is required. This function
- * takes the oxygen sensor data and setpoint values from the structures
- * of plotinfo and re-inserts the duplicate values set to 0 so
- * that the oxygen sensor data are complete and ready for plotting.
- * The original sequence of oxygen values are recreated without attempting
- * any interpolations for values set to zero, recreating the raw data from
- * the CCR dive log. This function called by: create_plot_info_new() */
+/* In the samples from each dive computer, there may be uninitialised oxygen
+ * sensor or setpoint values, e.g. when events were inserted into the dive log
+ * or if the dive computer does not report o2 values with every sample. But
+ * for drawing the profile a complete series of valid o2 pressure values is
+ * required. This function takes the oxygen sensor data and setpoint values
+ * from the structures of plotinfo and replaces the zero values with their
+ * last known values so that the oxygen sensor data are complete and ready
+ * for plotting. This function called by: create_plot_info_new() */
 {
 	int i, j;
 	double last_setpoint, last_sensor[3], o2pressure, amb_pressure;
 
 	for (i = 0; i < pi->nr; i++) {
 		struct plot_data *entry = pi->entry + i;
-		// For 1st iteration, initialise the last_ values
 		if (dc->

[PATCH 2/4] Make filter UI comply with capitalisation style

[Tim Wootton]

Signed-off-by: Tim Wootton 
---
 qt-ui/listfilter.ui | 2 +-
 qt-ui/mainwindow.ui | 2 +-
 qt-ui/models.cpp| 4 ++--
 qt-ui/simplewidgets.cpp | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/qt-ui/listfilter.ui b/qt-ui/listfilter.ui
index 016b776..2aec3e4 100644
--- a/qt-ui/listfilter.ui
+++ b/qt-ui/listfilter.ui
@@ -19,7 +19,7 @@
  
   

-TextLabel
+Text label

   
  
diff --git a/qt-ui/mainwindow.ui b/qt-ui/mainwindow.ui
index da7f26e..9374a5d 100644
--- a/qt-ui/mainwindow.ui
+++ b/qt-ui/mainwindow.ui
@@ -837,7 +837,7 @@ p, li { white-space: pre-wrap; }
   
   

-&Filter by Tags
+&Filter by tags


 Ctrl+F
diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index da4dc4f..89afb11 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -2427,7 +2427,7 @@ void BuddyFilterModel::repopulate()
}
}
qSort(list);
-   list << tr("No Buddies");
+   list << tr("No buddies");
setStringList(list);
delete[] checkState;
checkState = new bool[list.count()];
@@ -2544,7 +2544,7 @@ void LocationFilterModel::repopulate()
}
}
qSort(list);
-   list << tr("No Location set");
+   list << tr("No location set");
setStringList(list);
delete[] checkState;
checkState = new bool[list.count()];
diff --git a/qt-ui/simplewidgets.cpp b/qt-ui/simplewidgets.cpp
index c244425..a5707c3 100644
--- a/qt-ui/simplewidgets.cpp
+++ b/qt-ui/simplewidgets.cpp
@@ -485,7 +485,7 @@ BuddyFilter::BuddyFilter(QWidget *parent) : QWidget(parent)
 {
ui.setupUi(this);
ui.label->setText(tr("Person: "));
-   ui.label->setToolTip(tr("Searches for Buddies and Divemasters"));
+   ui.label->setToolTip(tr("Searches for buddies and divemasters"));
 #if QT_VERSION >= 0x05
ui.filterInternalList->setClearButtonEnabled(true);
 #endif
-- 
2.1.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 3/4] Adjusts tissue graph button

[Tim Wootton]

Tool tip not needed, text already provided on mouse-over
Corrects captitalisation style

Signed-off-by: Tim Wootton 
---
 qt-ui/mainwindow.ui | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/qt-ui/mainwindow.ui b/qt-ui/mainwindow.ui
index 9374a5d..8e5be3f 100644
--- a/qt-ui/mainwindow.ui
+++ b/qt-ui/mainwindow.ui
@@ -852,10 +852,7 @@ p, li { white-space: pre-wrap; }
  :/icon_tissue:/icon_tissue


-Toggle Tissue Graph
-   
-   
-Toggle Tissue Graph
+Toggle tissue graph

   
  
-- 
2.1.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 1/4] Text adjustments to configuredivecomputer

[Tim Wootton]

Use 2 subscript on ppO2
Adhere to agreed capitalisation style
Reset instead of resetted

Signed-off-by: Tim Wootton 
---
 configuredivecomputer.cpp|  2 +-
 qt-ui/configuredivecomputerdialog.ui | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configuredivecomputer.cpp b/configuredivecomputer.cpp
index 884b2dd..ad4430c 100644
--- a/configuredivecomputer.cpp
+++ b/configuredivecomputer.cpp
@@ -582,6 +582,6 @@ void ConfigureDiveComputer::resetThreadFinished()
setState(DONE);
if (resetThread->lastError.isEmpty()) {
//No error
-   emit message(tr("Device settings successfully resetted"));
+   emit message(tr("Device settings successfully reset"));
}
 }
diff --git a/qt-ui/configuredivecomputerdialog.ui 
b/qt-ui/configuredivecomputerdialog.ui
index f747330..d5deace 100644
--- a/qt-ui/configuredivecomputerdialog.ui
+++ b/qt-ui/configuredivecomputerdialog.ui
@@ -177,7 +177,7 @@
   
   

-Suunto Vyper Family
+Suunto Vyper family


 
@@ -602,7 +602,7 @@
   
   

-Advanced Settings
+Advanced settings


 
@@ -1213,14 +1213,14 @@
 
  
   
-   ppO2 max
+   ppO₂ max
   
  
 
 
  
   
-   ppO2 min
+   ppO₂ min
   
  
 
@@ -1470,7 +1470,7 @@
 
  
   
-   Total divetime
+   Total dive time
   
  
 
-- 
2.1.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 4/4] Capitalisation in file type list

[Tim Wootton]

Signed-off-by: Tim Wootton 
---
 qt-ui/diveshareexportdialog.ui | 2 +-
 qt-ui/mainwindow.cpp   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qt-ui/diveshareexportdialog.ui b/qt-ui/diveshareexportdialog.ui
index 051f4f3..b5e9240 100644
--- a/qt-ui/diveshareexportdialog.ui
+++ b/qt-ui/diveshareexportdialog.ui
@@ -55,7 +55,7 @@
 
  
   
-   Get UserID
+   Get user ID
   
  
 
diff --git a/qt-ui/mainwindow.cpp b/qt-ui/mainwindow.cpp
index c9515af..cc2d970 100644
--- a/qt-ui/mainwindow.cpp
+++ b/qt-ui/mainwindow.cpp
@@ -1249,7 +1249,7 @@ void MainWindow::on_actionImportDiveLog_triggered()
QStringList fileNames = QFileDialog::getOpenFileNames(this, tr("Open 
dive log file"), lastUsedDir(),
tr("Dive log files (*.xml *.uddf *.udcf *.csv *.jlb *.dld *.sde 
*.db *.can);;"
"XML files (*.xml);;UDDF/UDCF files(*.uddf 
*.udcf);;JDiveLog files(*.jlb);;"
-   "Suunto Files(*.sde *.db);;CSV Files(*.csv);;MkVI 
Files(*.txt);;All Files(*)"));
+   "Suunto files(*.sde *.db);;CSV files(*.csv);;MkVI 
files(*.txt);;All files(*)"));
 
if (fileNames.isEmpty())
return;
-- 
2.1.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 07:08:19PM -0400, John Van Ostrand wrote:
> Okay, you've convinced me. This is too big for me right now. I'll fiddle
> with smaller bits until I get a much better understanding of the code.

This wasn't my goal at all.

I would like you to work with me (and others) to continue down this path.
It's not an easy "over the weekend" kind of project. But that doesn't mean
that it isn't worth doing.

Let's start with one specific case and a proof of concept implementation.

E.g., let's add one step undo to edits. Don't mess with any of the
displayed_dive vs. current_dive semantics but just implement a way to
track "which dive was the last one changed" and "replace that dive with a
copy of it that we made before the last edit operation".

That should give you a good idea of all the areas of the code that this
needs to touch.

Then add the data structures that you envisioned for the undo / redo ring
buffer.

Once that is in place, you and I should figure out how we can work
together to convert from our displayed_dive / current_dive semantic to the
semantic that your approach implies where the connection between what's
displayed and what is in the dive_table is much tighter.

Does that make sense?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

new daily builds and preparing for Beta 1

[Dirk Hohndel]

I think I have everything applied - or responded to :-)

New daily builds are up for Windows (32 & 64bit) and Mac. It's 4.2-400.

Please play with the new multi filter functions and any and all other
features. As I mentioned, I want to do a first beta in a week.

So translators, please get started. The latest strings have been pushed
(but sorry, the binaries were build before I pulled the last translations,
so for those translators who already started, those changes aren't
reflected in the binaries).

Willem, I assume you will continue to drive the user manual (which of
course also drives its own translation team).

The CCR / PSCR code clearly needs more work.

What's the status of the planner?

I still want to have an easier "add dive" where the user simply gives a
max depth and has a checkbox whether they want a safety stop or not. This
is IN ADDITION to the current profile based editor.

There are quite a few open bugs in trac, I'll make another pass at some of
those. It would be nice if others would take a look as well.

We obviously want some version of EON Steel support (as well as all the
other new models that are in libdivecomputer).

I have a few more small things in mind that I can't remember right now :-)

Have a good weekend everyone!

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 5:43 PM, Dirk Hohndel  wrote:

> On Fri, Oct 31, 2014 at 04:36:29PM -0400, John Van Ostrand wrote:
> >
> > In other words when manually adding a dive an empty dive would be added
> to
> > the dive list with fields added to the dive in as they are entered in the
> > form.
>
> Hmm. I find that somewhat awkward. But I'm not categorically rejecting it.
>
> > > > This would have a few benefits
> > > >
> > > > 1. We eliminate the "This dive is being edited" indicator and all the
> > > code
> > > > referencing "isEditing()".
> > >
> > > So this is easy to write in text, but once you deal with the widgets it
> > > gets a little tricky.
> > >
> > > Example. You edit something (let's say a tag), your cursor is still in
> > > that field, and then click on a different dive in the dive list. What
> > > happens? You have a drop down open (date, cylinder type) and you
> change to
> > > a different dive...
> > >
> > > What I'm trying to say is that the definition of "I'm editing
> something"
> > > is very intuitive, until you try to implement the finer details.
> >
> > I figured we could use a change signal of some kind so we can react to
> > changes. It looks like some widgets are already enabled. Others may need
> > some modification.
>
> That's part of the 'how'. But the question in many instances is "when do
> you issue that signal". E.g., when changing a text field, do you issue
> this with every key press? If not, then when DO you do it? We have learned
> the hard way that it's not always simple to figure out when focus has
> moved...
>
> > > 2. We don't have anything funny to do with placemarks on the map.
> > > > 3. Oops, like accidental double clicks can be backed out.
> > > > 4. Eliminate non-intuitive location/placemark functionality.
> > > > 5. Any for_each_dive will automatically include the dive being
> edited so
> > > UI
> > > > updates like placemarks don't need special cases.
> > >
> > > That last one doesn't make sense to me. Can you elaborate.
> > >
> >
> > The repopulateLabels function in globe.cpp uses the dive list to create
> > flags. It would be cleaner if the data being editing was being updated
> into
> > the dive list as each field was changed. That way functions like
> > repopulateLabels wouldn't have to retrieve data from the form to place a
> > flag.
>
> Ah, OK. That's what I suggested with adding the displayed_dive there.
> But please DO NOT break the logic that the displayed_dive is distinct and
> different from the corresponding dive on the divelist...
>
> > > > There would be a few challenges:
> > > >
> > > > 1. Single dive edits would be easy but multi-dive edits would more
> > > > complicated. They should be associated as one undo.
> > >
> > > OK
> > >
> > > > 2. Trips would be another undo case.
> > >
> > > What does that mean? You mean trip changes to the divelist?
> > > Uhhh, I want to see the data structure in which you do that :-)
> >
> > We may want to undo a trip grouping or undo edits to a trip. We need to
> set
> > up different types of undos. A TRIP_GROUP undo might be one type and
> > TRIP_EDIT undo might be another. The undo stack would have a struct that
> > contains a type and a pointer to a blob of data, and undo action would
> send
> > that blob to the function that handles that specific undo type. The blob
> > would be used by that function to perform the undo. This provides a
> > framework for allowing a wide range of different undos.
>
> Wow. Oops. Err. Yeah. That sounds easy...
>
> > A example might be this (imagine expanding struct undo_dive_edit to hold
> a
> > list of dives.)
> >
> > struct undo_item {
> > enum undo_type type;
> > void *data;
> > };
> >
> > struct undo_dive_edit {
> >int divenr;
> >struct dive *dive;
> > };
> >
> > struct undo_item undo_stack[16];
> > int undo_stack_head = 0;
> > int undo_stack_tail = 0;
> >
> > // called when date field is updated
> > void MainTab::updateDate(const QDateTime &)
> > {
> >  undo_dive_create();   // create and undo for this change
> >  
> > }
> >
> >
> > void undo_dive_edit_create()
> > {
> >  struct undo_item undo = undo_get_current();   // Get most recent
> undo
> >  struct undo_dive_edit *ude = undo->undo_data;
> >
> >  // Only create an undo if this change affects a different set of
> dives
> > than the current undo.
> >  if (undo.type != UNDO_DIVE_EDIT || ude->dive == selected_dive)  {
> >  // Create undo item.
> >  struct undo_dive_edit *new_undo = malloc(sizeof(struct
> > undo_dive_edit));
> >  new_undo->divenr = selected_dive;
> >  new_undo->dive = 
> >  undo_push(UNDO_DIVE_EDIT, (void *) new_undo);
> >  }
> > }
> >
> >
> > // Dive Edit Undo
> > void undo_dive_edit(void *undo_data)
> > {
> >  struct undo_dive_edit *undo = undo->undo_data;
> >
> >  
> > }
> >
> >
> > void undo_pop()
> > {
> >
> >  if (undo_stack_head == undo_stack_tail)
> >  return; // nothing to undo
> >
> >  st

Re: PATCH: Remove code that zeroes oxygen-related data and temperatures

[Dirk Hohndel]

Git complains about a corrupt patch...

/D

On Fri, Oct 31, 2014 at 09:27:59PM +0200, Willem Ferguson wrote:
> 
> Remove code that zeroes out duplicate oxygen sensor and temperature values
> 
> Remove the code that changes all duplicate oxygen sensor, setpoint and
> temperature
> values from a dive log to zero. One of the motivations is that a zero
> setpoint
> value indicates an Open Circuit dive segment, not Closed Circuit Rebreather.
> The
> code in dive.c is removed and the comments for the corresponding restoration
> code that restores
> the last known values into sensor or temperature with zero values is
> [fill_o2_values()
> in profile.c] is changed to apply to the present situation.
> 
> Signed-off-by: willem ferguson 
> 
> I did some experimenting with the code that restores zeroed oxygen values to
> last-known values.
> If I remove the restoration code, then the o2 profile for the Poseidon data
> goes wonky: o2 values are
> not reported with every sample, so the restoration code is still required.
> Same applies to
> temperature data.
> Kind regards,
> willem
> 

> From 4801a22ec7493e41560300543d4bb20c9678847f Mon Sep 17 00:00:00 2001
> From: willem ferguson 
> Date: Fri, 31 Oct 2014 21:00:17 +0200
> Subject: [PATCH 2/2] Remove code that zeroes out duplicate oxygen sensor and
>  temperature values
> 
> Remove the code that changes all duplicate oxygen sensor, setpoint and 
> temperature
> values from a dive log to zero. One of the motivations is that a zero setpoint
> value indicates an Open Circuit dive segment, not Closed Circuit Rebreather. 
> The
> code in dive.c is removed and the comments for the corresponding code that 
> reinserts
> the last known values into sensor or temperature with zero values is 
> [fill_o2_values()
> in profile.c] is changed to apply to the present situation.
> 
> Signed-off-by: willem ferguson 
> ---
>  dive.c| 51 ++-
>  profile.c | 27 +++
>  2 files changed, 37 insertions(+), 41 deletions(-)
> 
> diff --git a/dive.c b/dive.c
> index 9f4df56..118ee2b 100644
> --- a/dive.c
> +++ b/dive.c
> @@ -1098,15 +1098,16 @@ static void fixup_dc_events(struct divecomputer *dc)
>  
>  static void fixup_dive_dc(struct dive *dive, struct divecomputer *dc)
>  {
> - int i, j, o2val;
> + int i, j;
>   double depthtime = 0;
>   int lasttime = 0;
>   int lastindex = -1;
>   int maxdepth = dc->maxdepth.mm;
>   int mintemp = 0;
>   int lastdepth = 0;
> - int lasttemp = 0, lastpressure = 0, lastdiluentpressure = 0;
> - int lasto2val[3] = { 0, 0, 0 };
> + int lastpressure = 0, lastdiluentpressure = 0;
>   int pressure_delta[MAX_CYLINDERS] = { INT_MAX, };
>   int first_cylinder;
>  
> @@ -1164,31 +1165,31 @@ static void fixup_dive_dc(struct dive *dive, struct 
> divecomputer *dc)
>   fixup_pressure(dive, sample);
>  
>   if (temp) {
> - /*
> -  * If we have consecutive identical
> -  * temperature readings, throw away
> -  * the redundant ones.
> -  */
> - if (lasttemp == temp)
> - sample->temperature.mkelvin = 0;
> - else
> - lasttemp = temp;
> -
>   if (!mintemp || temp < mintemp)
>   mintemp = temp;
>   }
> -
> - // If there are consecutive identical O2 sensor readings, throw 
> away the redundant ones.
> - for (j = 0; j < dc->no_o2sensors; j++) { // for CCR oxygen 
> sensor data:
> - o2val = sample->o2sensor[j].mbar;
> - if (o2val) {
> - if (lasto2val[j] == o2val)
> - sample->o2sensor[j].mbar = 0;
> - else
> - lasto2val[j] = o2val;
> - }
> - }
> -
>   update_min_max_temperatures(dive, sample->temperature);
>  
>   depthtime += (time - lasttime) * (lastdepth + depth) / 2;
> diff --git a/profile.c b/profile.c
> index 4bc9422..bc59c48 100644
> --- a/profile.c
> +++ b/profile.c
> @@ -929,30 +929,26 @@ static void calculate_gas_information_new(struct dive 
> *dive, struct plot_info *p
>  
>  void fill_o2_values(struct divecomputer *dc, struct plot_info *pi, struct 
> dive *dive)
>  /* For CCR:
> - * In the samples from each dive computer, any duplicate values for the
> - * oxygen sensors were removed (i.e. set to 0) in order to conserve
> - * storage space (see function fixup_dive_dc). But for drawing the profile
> - * a complete series of valid o2 pressure values is required. This function
> - * takes the oxygen sensor data and setpoint values from the structures
> - * of plotinfo and re-inserts the duplicate values set to 0 so
> - * that the oxyg

fix divelist selection

[Tomaz Canabrava]

I broke, I fix it.
From 1bcc62c921e9b5fa8877538efa0d564c1f76d585 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 19:56:07 -0200
Subject: [PATCH 32/32] Fix selection on the list model.

forgot to add that we used multiselection when I recreated
the dive list.

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/mainwindow.ui | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/qt-ui/mainwindow.ui b/qt-ui/mainwindow.ui
index 926e815..da7f26e 100644
--- a/qt-ui/mainwindow.ui
+++ b/qt-ui/mainwindow.ui
@@ -129,7 +129,11 @@

   
   
-   
+   
+
+ QAbstractItemView::ExtendedSelection
+
+   
   
  
 
-- 
2.1.3

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 04:36:29PM -0400, John Van Ostrand wrote:
> 
> In other words when manually adding a dive an empty dive would be added to
> the dive list with fields added to the dive in as they are entered in the
> form.

Hmm. I find that somewhat awkward. But I'm not categorically rejecting it.

> > > This would have a few benefits
> > >
> > > 1. We eliminate the "This dive is being edited" indicator and all the
> > code
> > > referencing "isEditing()".
> >
> > So this is easy to write in text, but once you deal with the widgets it
> > gets a little tricky.
> >
> > Example. You edit something (let's say a tag), your cursor is still in
> > that field, and then click on a different dive in the dive list. What
> > happens? You have a drop down open (date, cylinder type) and you change to
> > a different dive...
> >
> > What I'm trying to say is that the definition of "I'm editing something"
> > is very intuitive, until you try to implement the finer details.
> 
> I figured we could use a change signal of some kind so we can react to
> changes. It looks like some widgets are already enabled. Others may need
> some modification.

That's part of the 'how'. But the question in many instances is "when do
you issue that signal". E.g., when changing a text field, do you issue
this with every key press? If not, then when DO you do it? We have learned
the hard way that it's not always simple to figure out when focus has
moved...

> > 2. We don't have anything funny to do with placemarks on the map.
> > > 3. Oops, like accidental double clicks can be backed out.
> > > 4. Eliminate non-intuitive location/placemark functionality.
> > > 5. Any for_each_dive will automatically include the dive being edited so
> > UI
> > > updates like placemarks don't need special cases.
> >
> > That last one doesn't make sense to me. Can you elaborate.
> >
> 
> The repopulateLabels function in globe.cpp uses the dive list to create
> flags. It would be cleaner if the data being editing was being updated into
> the dive list as each field was changed. That way functions like
> repopulateLabels wouldn't have to retrieve data from the form to place a
> flag.

Ah, OK. That's what I suggested with adding the displayed_dive there.
But please DO NOT break the logic that the displayed_dive is distinct and
different from the corresponding dive on the divelist...

> > > There would be a few challenges:
> > >
> > > 1. Single dive edits would be easy but multi-dive edits would more
> > > complicated. They should be associated as one undo.
> >
> > OK
> >
> > > 2. Trips would be another undo case.
> >
> > What does that mean? You mean trip changes to the divelist?
> > Uhhh, I want to see the data structure in which you do that :-)
> 
> We may want to undo a trip grouping or undo edits to a trip. We need to set
> up different types of undos. A TRIP_GROUP undo might be one type and
> TRIP_EDIT undo might be another. The undo stack would have a struct that
> contains a type and a pointer to a blob of data, and undo action would send
> that blob to the function that handles that specific undo type. The blob
> would be used by that function to perform the undo. This provides a
> framework for allowing a wide range of different undos.

Wow. Oops. Err. Yeah. That sounds easy...

> A example might be this (imagine expanding struct undo_dive_edit to hold a
> list of dives.)
> 
> struct undo_item {
> enum undo_type type;
> void *data;
> };
> 
> struct undo_dive_edit {
>int divenr;
>struct dive *dive;
> };
> 
> struct undo_item undo_stack[16];
> int undo_stack_head = 0;
> int undo_stack_tail = 0;
> 
> // called when date field is updated
> void MainTab::updateDate(const QDateTime &)
> {
>  undo_dive_create();   // create and undo for this change
>  
> }
> 
> 
> void undo_dive_edit_create()
> {
>  struct undo_item undo = undo_get_current();   // Get most recent undo
>  struct undo_dive_edit *ude = undo->undo_data;
> 
>  // Only create an undo if this change affects a different set of dives
> than the current undo.
>  if (undo.type != UNDO_DIVE_EDIT || ude->dive == selected_dive)  {
>  // Create undo item.
>  struct undo_dive_edit *new_undo = malloc(sizeof(struct
> undo_dive_edit));
>  new_undo->divenr = selected_dive;
>  new_undo->dive = 
>  undo_push(UNDO_DIVE_EDIT, (void *) new_undo);
>  }
> }
> 
> 
> // Dive Edit Undo
> void undo_dive_edit(void *undo_data)
> {
>  struct undo_dive_edit *undo = undo->undo_data;
> 
>  
> }
> 
> 
> void undo_pop()
> {
> 
>  if (undo_stack_head == undo_stack_tail)
>  return; // nothing to undo
> 
>  struct undo_item undo = undo_stack[undo_stack_head--];
> 
>  switch (undo.type) {
>  case UNDO_DIVE_EDIT:
> undo_dive_edit(undo->data);
> break;
>  case UNDO_DIVE_DELETE:
> ...
>  }
> }

That looks like an interesting start. And hellishly fragile.
I'd be very careful to make sure we

[PATCH] Avoid repeated layout names

[Giuseppe Bilotta]

Multiple layouts had the same name="gridLayout_3". Fix by shifting all
the numbers up by 1.

Signed-off-by: Giuseppe Bilotta 
---
 qt-ui/configuredivecomputerdialog.ui | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/qt-ui/configuredivecomputerdialog.ui 
b/qt-ui/configuredivecomputerdialog.ui
index 6571837..f747330 100644
--- a/qt-ui/configuredivecomputerdialog.ui
+++ b/qt-ui/configuredivecomputerdialog.ui
@@ -1617,7 +1617,7 @@

 Basic settings

-   
+   
 
  
   
@@ -1812,7 +1812,7 @@

 Advanced Settings

-   
+   
 
  
   
@@ -2078,7 +2078,7 @@

 Gas settings

-   
+   
 
  
   
-- 
2.1.2.766.gaa23a90

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: About multi filtering.

[Dirk Hohndel]

Hey Tomaz

On Fri, Oct 31, 2014 at 06:00:07PM -0200, Tomaz Canabrava wrote:
> 
> I'v just send a patch bomb ( ~30 ) that implements correctly multi
> filtering for subsurface. I'v tested them and it seems to work without
> issues. but not all filter possibilities are created:

Amazing work. I had to do a couple minor adjustments while applying, but
so far it all looks good.

I haven't done a full code review, that's still in the works.

> what works:
> 
> divemaster and buddy,
> location,
> tags.

Yes - and it's awesome, exactly what I was hoping for.

:clap: :clap: :clap:

> to add a new filter the simplest way is to follow the last 10 patches of my
> builk that are a step - by - step guide on how the system works.
> 
> I know that there's a bit of boilerplate, this is because of the way how Qt
> model system works. I can remove a bit of it but it won't a good gain, so
> I'm leaving them there.
> 
> What's missing:
> 
> - Suits
> - Visibility
> - Rating
> ( anything more? )

I don't know if filtering by viz and rating makes sense. I know I through
it out there, but I'm more concerned that it will make the UI too
cluttered.

Speaking of which: this is my only concern. The placement of the filter
area. I think I'd prefer if it replaced the MainTab and Profile. And had a
simple way to just hide it / show it again. This way I can see more of the
dive list while applying filters.

The idea would be that the filters are visible (plus the dive list) while
I'm figuring out which filters I wanted. Then I hide the filters and work
with the filtered dives.

Maybe the logic could be this... if ANY filter is active, the filter turns
into am area of a single line height (20px or whatever - make it relative
to font size) that says "Show filter". That's between the MainTab and the
dive list. You click on this, the maintab and profile are replaced with
the filter UI, but at the bottom is still the same area, this time with
"Hide filter". And additionally there is "Clear and close filter" which
clears all the filters and makes that part of the UI go away. Ctrl-F
brings it back.

Does that explanation make any sense? If I had any talent at all I could
draw it

:-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 1/2] Add gas mixes to MK6 import

[Miika Turkia]

Signed-off-by: Miika Turkia 
---
 file.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/file.c b/file.c
index 42f8ef6..ad5b035 100644
--- a/file.c
+++ b/file.c
@@ -444,7 +444,7 @@ int parse_txt_file(const char *filename, const char *csv)
 * make sure the input .txt looks like proper MkVI file, then start 
parsing the .csv.
 */
if (MATCH(memtxt.buffer, "MkVI_Config") == 0) {
-   int d, m, y;
+   int d, m, y, he;
int hh = 0, mm = 0, ss = 0;
int prev_depth = 0, cur_sampletime = 0, prev_setpoint = -1;
bool has_depth = false, has_setpoint = false;
@@ -476,11 +476,15 @@ int parse_txt_file(const char *filename, const char *csv)
dive->cylinder[cur_cylinder_index].type.size.mliter = 3000;
dive->cylinder[cur_cylinder_index].type.workingpressure.mbar = 
20;
dive->cylinder[cur_cylinder_index].type.description = 
strdup("3l Mk6");
+   dive->cylinder[cur_cylinder_index].gasmix.o2.permille = 1000;
cur_cylinder_index++;
 
dive->cylinder[cur_cylinder_index].type.size.mliter = 3000;
dive->cylinder[cur_cylinder_index].type.workingpressure.mbar = 
20;
dive->cylinder[cur_cylinder_index].type.description = 
strdup("3l Mk6");
+   he = atoi(parse_mkvi_value(memtxt.buffer, "Helium percentage"));
+   dive->cylinder[cur_cylinder_index].gasmix.o2.permille = (100 - 
atoi(parse_mkvi_value(memtxt.buffer, "Nitrogen percentage")) - he) * 10;
+   dive->cylinder[cur_cylinder_index].gasmix.he.permille = he * 10;
cur_cylinder_index++;
 
dc = &dive->dc;
-- 
1.9.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 2/2] Add .txt to notes on MK6 import

[Miika Turkia]

Signed-off-by: Miika Turkia 
---
 file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/file.c b/file.c
index ad5b035..c22f29f 100644
--- a/file.c
+++ b/file.c
@@ -487,6 +487,9 @@ int parse_txt_file(const char *filename, const char *csv)
dive->cylinder[cur_cylinder_index].gasmix.he.permille = he * 10;
cur_cylinder_index++;
 
+   lineptr = strstr(memtxt.buffer, "Dive started at");
+   if (lineptr)
+   dive->notes = strdup(lineptr);
dc = &dive->dc;
 
/*
-- 
1.9.1

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 12:47 PM, Dirk Hohndel  wrote:

> On Fri, Oct 31, 2014 at 09:40:29AM -0700, Dirk Hohndel wrote:
> > > I've been able to make changes so the ui.coordinates field is updated
> but
> > > placing flags on the globe is more challenging. Since the edited
> location
> > > name and coordinates only exist in the ui.location and ui.coordinates
> > > variables the globe::repopulateLabels() function can't place a flag on
> the
> > > globe, repopulateLabels() uses the dive list for coordinates and
> labels.
> > > Adding code so it also checks isEditing() and places a flag based on
> the
> > > edited fields would add that functionality.
> >
> > It should use the data from displayed_dive in addition to the dive list.
> > Then all you need to do is make sure things are tracked correctly in
> > displayed_dive (and they should, if not, that's yet another bug).
>
> Oh, and in case this wasn't obvious... my sentence implied the suggestion
> that you should implement that. So I won't tackle this and focus on the
> other three dozen bugs that I'm aware of


Jedi management tricks. ;)

-- 
John Van Ostrand
At large on sabbatical
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 12:34 PM, Dirk Hohndel  wrote:

> On Fri, Oct 31, 2014 at 11:39:27AM -0400, John Van Ostrand wrote:
> >
> > Mentioning Undo got me thinking.
> >
> > I've been mucking about trying to have globe.cpp both update the editted
> > dive *and* show the currently edit's placemark planted on the globe and
> the
> > code is uglier than I like. The idea of "undo" has me thinking of ways to
> > streamline that code and remove some oddities in the UI.
>
> He.
>
> > How about this.
> >
> > When editing dives we update the dive on each field change, storing the
> old
> > dive in an undo stack. We can accumulate similar consecutive edits to
> > reduce the number of undos.
>
> OK. That seems simple. Except when editing multiple dives. Then it gets...
> interesting. But I'll go with the idea.
>
> > This could include gas changes, events and even changes to the profile.
>
> Yep, I can see that.
>
> > Manually added dives can be done like this too.
>
> You lost me.
>

In other words when manually adding a dive an empty dive would be added to
the dive list with fields added to the dive in as they are entered in the
form.


>
> > This would have a few benefits
> >
> > 1. We eliminate the "This dive is being edited" indicator and all the
> code
> > referencing "isEditing()".
>
> So this is easy to write in text, but once you deal with the widgets it
> gets a little tricky.
>
> Example. You edit something (let's say a tag), your cursor is still in
> that field, and then click on a different dive in the dive list. What
> happens? You have a drop down open (date, cylinder type) and you change to
> a different dive...
>
> What I'm trying to say is that the definition of "I'm editing something"
> is very intuitive, until you try to implement the finer details.
>

I figured we could use a change signal of some kind so we can react to
changes. It looks like some widgets are already enabled. Others may need
some modification.

> 2. We don't have anything funny to do with placemarks on the map.
> > 3. Oops, like accidental double clicks can be backed out.
> > 4. Eliminate non-intuitive location/placemark functionality.
> > 5. Any for_each_dive will automatically include the dive being edited so
> UI
> > updates like placemarks don't need special cases.
>
> That last one doesn't make sense to me. Can you elaborate.
>

The repopulateLabels function in globe.cpp uses the dive list to create
flags. It would be cleaner if the data being editing was being updated into
the dive list as each field was changed. That way functions like
repopulateLabels wouldn't have to retrieve data from the form to place a
flag.

>
> > There would be a few challenges:
> >
> > 1. Single dive edits would be easy but multi-dive edits would more
> > complicated. They should be associated as one undo.
>
> OK
>
> > 2. Trips would be another undo case.
>
> What does that mean? You mean trip changes to the divelist?
> Uhhh, I want to see the data structure in which you do that :-)
>

We may want to undo a trip grouping or undo edits to a trip. We need to set
up different types of undos. A TRIP_GROUP undo might be one type and
TRIP_EDIT undo might be another. The undo stack would have a struct that
contains a type and a pointer to a blob of data, and undo action would send
that blob to the function that handles that specific undo type. The blob
would be used by that function to perform the undo. This provides a
framework for allowing a wide range of different undos.

A example might be this (imagine expanding struct undo_dive_edit to hold a
list of dives.)

struct undo_item {
enum undo_type type;
void *data;
};

struct undo_dive_edit {
   int divenr;
   struct dive *dive;
};

struct undo_item undo_stack[16];
int undo_stack_head = 0;
int undo_stack_tail = 0;

// called when date field is updated
void MainTab::updateDate(const QDateTime &)
{
 undo_dive_create();   // create and undo for this change
 
}


void undo_dive_edit_create()
{
 struct undo_item undo = undo_get_current();   // Get most recent undo
 struct undo_dive_edit *ude = undo->undo_data;

 // Only create an undo if this change affects a different set of dives
than the current undo.
 if (undo.type != UNDO_DIVE_EDIT || ude->dive == selected_dive)  {
 // Create undo item.
 struct undo_dive_edit *new_undo = malloc(sizeof(struct
undo_dive_edit));
 new_undo->divenr = selected_dive;
 new_undo->dive = 
 undo_push(UNDO_DIVE_EDIT, (void *) new_undo);
 }
}


// Dive Edit Undo
void undo_dive_edit(void *undo_data)
{
 struct undo_dive_edit *undo = undo->undo_data;

 
}


void undo_pop()
{

 if (undo_stack_head == undo_stack_tail)
 return; // nothing to undo

 struct undo_item undo = undo_stack[undo_stack_head--];

 switch (undo.type) {
 case UNDO_DIVE_EDIT:
undo_dive_edit(undo->data);
break;
 case UNDO_DIVE_DELETE:
...
 }
}


> > 3. We'd still have the issue of ac

Re: CSV import of Poseidon dive logs

[Miika Turkia]

On Fri, Oct 31, 2014 at 9:46 PM, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

>
> There are two issues:
> 1) The easy one: Is it possible to extract the text information from the
> contol file(*.txt) and insert that into the notes text box of the dive
> Notes tab? The hex at the top of that file should not be included in the
> notes text box. The text is pretty important info reflecting many things in
> the setup prior to diving and also several other things during the dive.
>

will do


> 2) The more difficult one. The start and end pressures of the diluent
> cylinder should be entered into the second row of the cylinders table in
> the Equipment tab (the 1st row represents the o2 cylinder) Currently the
> values are empty.
>

The diluent pressure should actually be already there. I'll have to see
where the bug is hiding to fix it...

>
> I think that would, for the moment, complete the import part for the
> Poseidon.
>
> How much of this is easily doable?
>

Shouldn't cause any problems. I'll try to get some coding done tomorrow
(provided I get all the sources and devel environment on my "new" laptop
before a flight).


> Thank you VERY much for your time.
>

no problemo

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

About multi filtering.

[Tomaz Canabrava]

People,

I'v just send a patch bomb ( ~30 ) that implements correctly multi
filtering for subsurface. I'v tested them and it seems to work without
issues. but not all filter possibilities are created:

what works:

divemaster and buddy,
location,
tags.

to add a new filter the simplest way is to follow the last 10 patches of my
builk that are a step - by - step guide on how the system works.

I know that there's a bit of boilerplate, this is because of the way how Qt
model system works. I can remove a bit of it but it won't a good gain, so
I'm leaving them there.

What's missing:

- Suits
- Visibility
- Rating
( anything more? )


Tomaz
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: CSV import of Poseidon dive logs

[Willem Ferguson]

On 30/10/2014 22:16, Miika Turkia wrote:
On Wed, Oct 29, 2014 at 8:12 PM, Willem Ferguson 
> wrote:


Miika,

I just submitted a patch that addresses the bug you found relating
to setpoint data. I hope this problem is solved.
When using your import code, the o2 partial pressure (calculated
in calculate_ccr_po2() in profile.c) should be plotted underneath
the depth profile. The current o2 partial pressure graph is
erroneous and looks like the setpoint, not the o2 partial
pressure. The patch I submitted does not solve this plotting
problem. Would you by any chance be prepared to have a look?


Number of O2 sensors was not set. Patch sent. (I assume that 2 is 
correct number for MK6.)


miika


Miika,

Thank you, this works perfectly!

There are two issues:
1) The easy one: Is it possible to extract the text information from the 
contol file(*.txt) and insert that into the notes text box of the dive 
Notes tab? The hex at the top of that file should not be included in the 
notes text box. The text is pretty important info reflecting many things 
in the setup prior to diving and also several other things during the dive.
2) The more difficult one. The start and end pressures of the diluent 
cylinder should be entered into the second row of the cylinders table in 
the Equipment tab (the 1st row represents the o2 cylinder) Currently the 
values are empty.


I think that would, for the moment, complete the import part for the 
Poseidon.


How much of this is easily doable?
Thank you VERY much for your time.
Kind regards,
willem
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

PATCH: Remove code that zeroes oxygen-related data and temperatures

[Willem Ferguson]

Remove code that zeroes out duplicate oxygen sensor and temperature values

Remove the code that changes all duplicate oxygen sensor, setpoint and 
temperature
values from a dive log to zero. One of the motivations is that a zero 
setpoint
value indicates an Open Circuit dive segment, not Closed Circuit 
Rebreather. The
code in dive.c is removed and the comments for the corresponding 
restoration code that restores
the last known values into sensor or temperature with zero values is 
[fill_o2_values()

in profile.c] is changed to apply to the present situation.

Signed-off-by: willem ferguson 

I did some experimenting with the code that restores zeroed oxygen 
values to last-known values.
If I remove the restoration code, then the o2 profile for the Poseidon 
data goes wonky: o2 values are
not reported with every sample, so the restoration code is still 
required. Same applies to

temperature data.
Kind regards,
willem

>From 4801a22ec7493e41560300543d4bb20c9678847f Mon Sep 17 00:00:00 2001
From: willem ferguson 
Date: Fri, 31 Oct 2014 21:00:17 +0200
Subject: [PATCH 2/2] Remove code that zeroes out duplicate oxygen sensor and
 temperature values

Remove the code that changes all duplicate oxygen sensor, setpoint and temperature
values from a dive log to zero. One of the motivations is that a zero setpoint
value indicates an Open Circuit dive segment, not Closed Circuit Rebreather. The
code in dive.c is removed and the comments for the corresponding code that reinserts
the last known values into sensor or temperature with zero values is [fill_o2_values()
in profile.c] is changed to apply to the present situation.

Signed-off-by: willem ferguson 
---
 dive.c| 51 ++-
 profile.c | 27 +++
 2 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/dive.c b/dive.c
index 9f4df56..118ee2b 100644
--- a/dive.c
+++ b/dive.c
@@ -1098,15 +1098,16 @@ static void fixup_dc_events(struct divecomputer *dc)
 
 static void fixup_dive_dc(struct dive *dive, struct divecomputer *dc)
 {
-	int i, j, o2val;
+	int i, j;
 	double depthtime = 0;
 	int lasttime = 0;
 	int lastindex = -1;
 	int maxdepth = dc->maxdepth.mm;
 	int mintemp = 0;
 	int lastdepth = 0;
-	int lasttemp = 0, lastpressure = 0, lastdiluentpressure = 0;
-	int lasto2val[3] = { 0, 0, 0 };
+	int lastpressure = 0, lastdiluentpressure = 0;
 	int pressure_delta[MAX_CYLINDERS] = { INT_MAX, };
 	int first_cylinder;
 
@@ -1164,31 +1165,31 @@ static void fixup_dive_dc(struct dive *dive, struct divecomputer *dc)
 		fixup_pressure(dive, sample);
 
 		if (temp) {
-			/*
-			 * If we have consecutive identical
-			 * temperature readings, throw away
-			 * the redundant ones.
-			 */
-			if (lasttemp == temp)
-sample->temperature.mkelvin = 0;
-			else
-lasttemp = temp;
-
 			if (!mintemp || temp < mintemp)
 mintemp = temp;
 		}
-
-		// If there are consecutive identical O2 sensor readings, throw away the redundant ones.
-		for (j = 0; j < dc->no_o2sensors; j++) { // for CCR oxygen sensor data:
-			o2val = sample->o2sensor[j].mbar;
-			if (o2val) {
-if (lasto2val[j] == o2val)
-	sample->o2sensor[j].mbar = 0;
-else
-	lasto2val[j] = o2val;
-			}
-		}
-
 		update_min_max_temperatures(dive, sample->temperature);
 
 		depthtime += (time - lasttime) * (lastdepth + depth) / 2;
diff --git a/profile.c b/profile.c
index 4bc9422..bc59c48 100644
--- a/profile.c
+++ b/profile.c
@@ -929,30 +929,26 @@ static void calculate_gas_information_new(struct dive *dive, struct plot_info *p
 
 void fill_o2_values(struct divecomputer *dc, struct plot_info *pi, struct dive *dive)
 /* For CCR:
- * In the samples from each dive computer, any duplicate values for the
- * oxygen sensors were removed (i.e. set to 0) in order to conserve
- * storage space (see function fixup_dive_dc). But for drawing the profile
- * a complete series of valid o2 pressure values is required. This function
- * takes the oxygen sensor data and setpoint values from the structures
- * of plotinfo and re-inserts the duplicate values set to 0 so
- * that the oxygen sensor data are complete and ready for plotting.
- * The original sequence of oxygen values are recreated without attempting
- * any interpolations for values set to zero, recreating the raw data from
- * the CCR dive log. This function called by: create_plot_info_new() */
+ * In the samples from each dive computer, there may be uninitialised oxygen
+ * sensor or setpoint values, e.g. when events were inserted into the dive log
+ * or if the dive computer does not report o2 values with every sample. But
+ * for drawing the profile a complete series of valid o2 pressure values is
+ * required. This function takes the oxygen sensor data and setpoint values
+ * from the structures of plotinfo and replaces the zero values with their
+ * last known values so that the oxygen sensor data are complete and ready
+ * for plotting. This function called by: create_plot_info_new(

Re: WIP: MultiFilter

[Tomaz Canabrava]

now, Buddy Filtering is done. get it while it's hot.

On Fri, Oct 31, 2014 at 4:39 PM, Davide DB  wrote:

> Woow
>
> davide@mobile
> Il 31/ott/2014 19:08 "Tomaz Canabrava"  ha scritto:
>
>> Dirk,
>>
>> This is a WIP but it's safe to add.
>> What's missing: The other filters.
>>
>> But the layout, interaction, etc, is the final one, so I think you guys (
>> specially you and deivide ) should take a look.
>>
>> ctrl + f or menu item toggle the filtering.
>>
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>>
From 046bc9e1e3a8fff01b7a8cb36be4dfde86c77c1f Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 16:20:43 -0200
Subject: [PATCH 10/19] Added the skeleton for the BuddyFilter

Just the skeleton of the functions, nothing working yet.

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/models.cpp | 36 
 qt-ui/models.h   | 19 +++
 2 files changed, 55 insertions(+)

diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index e4df205..2e78f1b 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -2351,6 +2351,42 @@ bool TagFilterModel::filterRow(int source_row, const QModelIndex &source_parent,
 	return false;
 }
 
+BuddyFilterModel::BuddyFilterModel(QObject *parent)
+{
+
+}
+
+BuddyFilterModel *BuddyFilterModel::instance()
+{
+
+}
+
+bool BuddyFilterModel::filterRow(int source_row, const QModelIndex &source_parent, QAbstractItemModel *sourceModel) const
+{
+
+}
+
+Qt::ItemFlags BuddyFilterModel::flags(const QModelIndex &index) const
+{
+	return QStringListModel::flags(index);
+}
+
+void BuddyFilterModel::repopulate()
+{
+
+}
+
+QVariant BuddyFilterModel::data(const QModelIndex &index, int role) const
+{
+	return QStringListModel::data(index, role);
+}
+
+
+bool BuddyFilterModel::setData(const QModelIndex &index, const QVariant &value, int role)
+{
+	return QStringListModel::setData(index, value, role);
+}
+
 MultiFilterSortModel *MultiFilterSortModel::instance()
 {
 	static MultiFilterSortModel *self = new MultiFilterSortModel();
diff --git a/qt-ui/models.h b/qt-ui/models.h
index 032edc5..fb92d27 100644
--- a/qt-ui/models.h
+++ b/qt-ui/models.h
@@ -443,6 +443,25 @@ private:
 	explicit TagFilterModel(QObject *parent = 0);
 };
 
+class BuddyFilterModel : public QStringListModel, public MultiFilterInterface{
+	Q_OBJECT
+public:
+	static BuddyFilterModel *instance();
+	virtual QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const;
+	virtual bool setData(const QModelIndex &index, const QVariant &value, int role = Qt::EditRole);
+	virtual Qt::ItemFlags flags(const QModelIndex &index) const;
+	virtual bool filterRow(int source_row, const QModelIndex &source_parent, QAbstractItemModel *sourceModel) const;
+	bool *checkState;
+	bool anyChecked;
+public
+slots:
+	void repopulate();
+
+private:
+	explicit BuddyFilterModel(QObject *parent = 0);
+};
+
+
 class MultiFilterSortModel : public QSortFilterProxyModel {
 	Q_OBJECT
 public:
-- 
2.1.3

From 0ab946aaa799d644e7d0169fc82b1f7ef7c1a789 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 16:21:33 -0200
Subject: [PATCH 11/19] Implemented the instance method for the BuddyFilter

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/models.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index 2e78f1b..dca8d74 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -2358,7 +2358,8 @@ BuddyFilterModel::BuddyFilterModel(QObject *parent)
 
 BuddyFilterModel *BuddyFilterModel::instance()
 {
-
+	static BuddyFilterModel *self = new BuddyFilterModel();
+	return self;
 }
 
 bool BuddyFilterModel::filterRow(int source_row, const QModelIndex &source_parent, QAbstractItemModel *sourceModel) const
-- 
2.1.3

From 2a720e3cbadd8ae17c8b2ee1b8b20711f68a91ec Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 16:22:30 -0200
Subject: [PATCH 12/19] Implemented the constructor for the BuddyFilter

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/models.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index dca8d74..4972fbf 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -2351,7 +2351,7 @@ bool TagFilterModel::filterRow(int source_row, const QModelIndex &source_parent,
 	return false;
 }
 
-BuddyFilterModel::BuddyFilterModel(QObject *parent)
+BuddyFilterModel::BuddyFilterModel(QObject *parent) : QStringListModel(parent), checkState(NULL)
 {
 
 }
-- 
2.1.3

From e5e4f8becf3229348928727163197dc14ab1e0ea Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 16:23:20 -0200
Subject: [PATCH 13/19] Impelmented the Data method for BuddyFilter

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/models.cpp | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index 

Re: WIP: MultiFilter

[Davide DB]

Woow

davide@mobile
Il 31/ott/2014 19:08 "Tomaz Canabrava"  ha scritto:

> Dirk,
>
> This is a WIP but it's safe to add.
> What's missing: The other filters.
>
> But the layout, interaction, etc, is the final one, so I think you guys (
> specially you and deivide ) should take a look.
>
> ctrl + f or menu item toggle the filtering.
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Import Datatrak/WLog files

[Salvador Cuñat]

2014-10-27 4:16 GMT+01:00 Dirk Hohndel :

>
> > Datatrak/Wlog files include a lot of diving data which are not directly
> > supported in Subsurface, in these cases we choose mostly to use "tags".
>
> Why is this (and the following comments) in "we" form? Did you collaborate
> with someone on these patches?
>

I didn't, but, when  writing english I tend to use "we" to avoid the
constat repetition I,I,I,me,me,me ...
I know, I know, I'm too shy  ;-)   We (spanish) don't have that problem as
our verb forms includes
the person in most situations.


> > BTW, in Example.log, 0x00 identifier is used for some DC dives and from
> my own
> > divelogs is inferred that 0x00 is used for manually entered dives, this
> could
> > easily be an error in Example.log coming from a preproduction DC model.
>
> Have you found others who have old divelogs from this software?
>

No.  The divers I know  who are still using Aladin  (Air X/Z, Pro, ...) nor
even download the
info from their DCs  (and probably never did).  Said this, I still see a
number of those devices in use,
but don't know  all those guys.  My son (16 y.o. and recently certified
OWD) has just inherited his
uncle's Aladin Pro;  now he only needs his father to build an interface to
download the data (which
can be very, very, long time as I'm a real moron with the soldering iron).

> +
> +
> +static int two_bytes_to_int(unsigned char x, unsigned char y) {
> +
> + return (x << 8) + y;
> +}

Take a look at the coding style. The opening '{' on a function should be
> in column 1 of the folowing line. This seems to be wrong everywhere.
>
>
Unforgivable.  Never did like this before. When I noticed, I thought it was
because of the
settings in QT-Creator taken from the CodingStyle file and didn't paid more
attention.
Corrected in the whole file.

Also, this function will get you in trouble on systems where int is only
> 16 bits (admittedly, not a major concern these days, but on principle...
> why is the result signed?)
>
> > +static long four_bytes_to_long(unsigned char x, unsigned char y,
> unsigned char z, unsigned char t) {
> > +
> > + return (((long)x << 24) + ((long)y << 16) + ((long)z << 8) +
> ((long)t));
> > +}
>
> Same comments again. If long is 32 bit you are in trouble. Can this be
> unsigned, please?
>
> > +static unsigned char* byte_to_bits(unsigned char byte) {
> > +
> > + unsigned char i, *bits = (unsigned char*) malloc(8 *
> sizeof(unsigned char));
>
> sizeof(unsigned char) is always 1. Well, technically that's only
> guaranteed in C++, I guess. But I'm not aware of any C compiler today
> (certainly not on Windows, Mac, Linux) that does anything else.
>
> Changed to unsigned both of them. You are right, off course.


> > +
> > + for (i = 0; i < 8; i++) {
> > + bits[i] = (byte & (unsigned char) pow(2,i))/pow(2,i);
>
> Yikes... this can be done much easier with shifts...
>

Sure.  Also, bits[i] don't needs to be 0 or 1, just  != 0 so changed to
bits[i] = (byte & (1 << i));

>
> > +static time_t date_time_to_ssrfc(long date, int time) {
> > +
> > + time_t tmp;
> > + tmp = ((date -135140)*86400)+(time*60);
> > + return tmp;
> > +}
>
> Fascinating formula - seriously, this is in days since Jan 1st, 1600?
> This really deserves a comment, don't you think?
>
>
Seriously.  It don't seems to come from aladin data, probably is a datatrak
"feature".
May be those guys were remembering Giordano Bruno burnt to death in the
pyre of
the Inquisition.  Don't know.
Commented on the code.


This also deserves some comments
> > +
> > +/*
> > + * Shameless copy paste from dive.c add_sample() with ligth changes
>
> ligth?
>
> I meant "slight".  add_sample() seems excessively complex for its job. I
thik we don't
really need to pass the pointer to the predefined sample structure, just to
catch the
returned one.  This said add_sample() is working fine from long, so I've
moved the
code to it, removing add_dt_sample().


> > + */
> > +static struct sample *add_dt_sample(int time, struct divecomputer *dc)
> > +{
> > + struct sample *p = prepare_sample(dc);
> > +
> > + if (p) {
> > + p->time.seconds = time;
> > + finish_sample(dc);
> > + }
> > + return p;
> > +}
>


> > + if (two_bytes_to_int (lector_bytes[0],lector_bytes[1]) != 0xA000) {
>
> more whitespace issues.^^^
>

> + printf("ERROR, Byte = %4x\n", two_bytes_to_int
> (lector_bytes[0],lector_bytes[1]));
>
> and more of the same.
>
> H, this kind issues are difficult to completely avoid.   Re-readed the
full code and found some
more, all  fixed, but may be there are more here and there.

> + switch (tmp_1byte) {
> > + case 1:
> > + dt_dive->dc.surface_pressure.mbar = 1013;
> > + break;
> > + case 2:
> > + dt_dive->dc.surface_pressure.mbar = 928;
> > + brea

WIP: MultiFilter

[Tomaz Canabrava]

Dirk,

This is a WIP but it's safe to add.
What's missing: The other filters.

But the layout, interaction, etc, is the final one, so I think you guys (
specially you and deivide ) should take a look.

ctrl + f or menu item toggle the filtering.
From 595bb5e4b0d38b887fc30cb972d6d10112eb39e7 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 13:44:21 -0200
Subject: [PATCH 1/9] Move the Filter to a better position

This patch moves the filter from the collapsable pannel
and puts it in an uncollapsable way above the dive list.

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/mainwindow.ui | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/qt-ui/mainwindow.ui b/qt-ui/mainwindow.ui
index 8434111..4d1f4b4 100644
--- a/qt-ui/mainwindow.ui
+++ b/qt-ui/mainwindow.ui
@@ -123,29 +123,18 @@
 
  0
 
-
- 
-  true
- 
- 
-  QAbstractItemView::ExtendedSelection
- 
- 
-  true
- 
- 
-  false
- 
- 
-  true
- 
- 
-  true
- 
+
+ 
+  
+   
+  
+  
+   
+  
+ 
 
 

-   

 
  0
@@ -256,7 +245,7 @@ p, li { white-space: pre-wrap; }
  0
  0
  1682
- 22
+ 36
 


@@ -844,7 +833,7 @@ p, li { white-space: pre-wrap; }
   
   

-Filter by Tags
+&Filter by Tags

   
   
-- 
2.1.3

From 24edb0c0428040ad73e8c8bb308ac96f9ea33050 Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 14:00:52 -0200
Subject: [PATCH 2/9] Do not allow to collapse the pannels of the mainwindow

Disable the possibility to collapse the pannel in the
mainwindow when seeing everything.

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/mainwindow.cpp | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/qt-ui/mainwindow.cpp b/qt-ui/mainwindow.cpp
index 1d4b22a..586be85 100644
--- a/qt-ui/mainwindow.cpp
+++ b/qt-ui/mainwindow.cpp
@@ -561,8 +561,18 @@ void MainWindow::on_actionYearlyStatistics_triggered()
 }
 
 #define BEHAVIOR QList()
+
+#define TOGGLE_COLLAPSABLE( X ) \
+	ui.mainSplitter->setCollapsible(0, X); \
+	ui.mainSplitter->setCollapsible(1, X); \
+	ui.infoProfileSplitter->setCollapsible(0, X); \
+	ui.infoProfileSplitter->setCollapsible(1, X); \
+	ui.listGlobeSplitter->setCollapsible(0, X); \
+	ui.listGlobeSplitter->setCollapsible(1, X);
+
 void MainWindow::on_actionViewList_triggered()
 {
+	TOGGLE_COLLAPSABLE( true );
 	beginChangeState(LIST_MAXIMIZED);
 	ui.listGlobeSplitter->setSizes(BEHAVIOR << EXPANDED << COLLAPSED);
 	ui.mainSplitter->setSizes(BEHAVIOR << COLLAPSED << EXPANDED);
@@ -570,6 +580,7 @@ void MainWindow::on_actionViewList_triggered()
 
 void MainWindow::on_actionViewProfile_triggered()
 {
+	TOGGLE_COLLAPSABLE( true );
 	beginChangeState(PROFILE_MAXIMIZED);
 	ui.infoProfileSplitter->setSizes(BEHAVIOR << COLLAPSED << EXPANDED);
 	ui.mainSplitter->setSizes(BEHAVIOR << EXPANDED << COLLAPSED);
@@ -577,6 +588,7 @@ void MainWindow::on_actionViewProfile_triggered()
 
 void MainWindow::on_actionViewInfo_triggered()
 {
+	TOGGLE_COLLAPSABLE( true );
 	beginChangeState(INFO_MAXIMIZED);
 	ui.infoProfileSplitter->setSizes(BEHAVIOR << EXPANDED << COLLAPSED);
 	ui.mainSplitter->setSizes(BEHAVIOR << EXPANDED << COLLAPSED);
@@ -584,6 +596,7 @@ void MainWindow::on_actionViewInfo_triggered()
 
 void MainWindow::on_actionViewGlobe_triggered()
 {
+	TOGGLE_COLLAPSABLE( true );
 	beginChangeState(GLOBE_MAXIMIZED);
 	ui.mainSplitter->setSizes(BEHAVIOR << COLLAPSED << EXPANDED);
 	ui.listGlobeSplitter->setSizes(BEHAVIOR << COLLAPSED << EXPANDED);
@@ -592,6 +605,7 @@ void MainWindow::on_actionViewGlobe_triggered()
 
 void MainWindow::on_actionViewAll_triggered()
 {
+	TOGGLE_COLLAPSABLE( false );
 	beginChangeState(VIEWALL);
 	static QList mainSizes;
 	const int appH = qApp->desktop()->size().height();
@@ -630,8 +644,16 @@ void MainWindow::on_actionViewAll_triggered()
 		ui.infoProfileSplitter->setSizes(infoProfileSizes);
 		ui.listGlobeSplitter->setSizes(listGlobeSizes);
 	}
+	ui.mainSplitter->setCollapsible(0, false);
+	ui.mainSplitter->setCollapsible(1, false);
+	ui.infoProfileSplitter->setCollapsible(0, false);
+	ui.infoProfileSplitter->setCollapsible(1, false);
+	ui.listGlobeSplitter->setCollapsible(0,false);
+	ui.listGlobeSplitter->setCollapsible(1,false);
 }
 
+#undef TOGGLE_COLLAPSABLE
+
 void MainWindow::beginChangeState(CurrentState s)
 {
 	if (state == VIEWALL && state != s) {
-- 
2.1.3

From fd3814dfc17a9e08e5c009392d75a2801ce6993f Mon Sep 17 00:00:00 2001
From: Tomaz Canabrava 
Date: Fri, 31 Oct 2014 14:05:52 -0200
Subject: [PATCH 3/9] Make possible to hide the tag filter.

It was impossible to remove the tag filter after opening it.

Signed-off-by: Tomaz Canabrava 
---
 qt-ui/mainwindow.cpp | 2 +-
 1 file changed, 1 inse

Re: messing with the gas / tank handling

[Davide DB]

On Fri, Oct 31, 2014 at 5:43 PM, Dirk Hohndel  wrote:

>
> Yes. So tell us in small words and short sentences ( :-) ) what it is that
> you would like and what the various bugs and missing features are.
>
> Ideally one at a time.
>
> I'm not trying to be funny - but it's really really hard to debug this /
> write the code when you don't quite understand what's wrong.
>
> For the developers usually the way we use things work. Otherwise we'd fix
> it :-)
>
>
I understand. I always try to be as precise as possible. Lately I 'm using
screencast because an illustration (video) is better than thousand words.

I have to dig into my old bug submissions related to gas management to
rebuild the whole story.
It seems to remember that:

- I should clearly identify my first/main tank and change whenever I like.
- I could have two or more identical tanks with same gas.
- The logic behind the current cylinder in use it's obscure.
- I would like to arrange tank order in the cylinder table.
- Current gas SAC stats are completely broken

I'm under the impression that the wonderful copy-paste procedure is messing
with current cilinder mistery.
I was trying to screencast the dive with ALL cylinders being current but
obviously after restarting Subsurface everything works.

Sorry about this but editing 12 technical dives with 4/5 different
cylinders and gases and dealing at the same time with:

http://trac.subsurface-divelog.org/ticket/753
http://trac.subsurface-divelog.org/ticket/754
http://trac.subsurface-divelog.org/ticket/732
 (solved but not in my
current build)
http://trac.subsurface-divelog.org/ticket/738
 (solved but not in my
current build)

And maybe other bugs (on current cylinder) is like running on a minefield
and only thinking to download and fill some other dives is like an incubus.

Bye

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 09:40:29AM -0700, Dirk Hohndel wrote:
> > I've been able to make changes so the ui.coordinates field is updated but
> > placing flags on the globe is more challenging. Since the edited location
> > name and coordinates only exist in the ui.location and ui.coordinates
> > variables the globe::repopulateLabels() function can't place a flag on the
> > globe, repopulateLabels() uses the dive list for coordinates and labels.
> > Adding code so it also checks isEditing() and places a flag based on the
> > edited fields would add that functionality.
> 
> It should use the data from displayed_dive in addition to the dive list.
> Then all you need to do is make sure things are tracked correctly in
> displayed_dive (and they should, if not, that's yet another bug).

Oh, and in case this wasn't obvious... my sentence implied the suggestion
that you should implement that. So I won't tackle this and focus on the
other three dozen bugs that I'm aware of.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: messing with the gas / tank handling

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 05:08:54PM +0100, Davide DB wrote:
>  If I correctly understand this topic, its' about the same old rant about
> cylinder  management...
> 
> I hope this could be solved in 4.4 at least.
> I'm editing multiple technical dives after a week of training and it's a
> nightmare between bugs and missing functionalities.
> While testing bugs 753 and 754 I realized that some dives have the "current
> cylinder in use" PITA on all of them.
> Actually I do not understand why in a row of six imported dives just a
> couple of them have this problem on all cylinders.

Sorry - as far as bug reports go... this one isn't really helping me
understand what's going wrong.

> - I never touched profiles
> - I played with copy & paste on multiple tanks and god knows what happened.
> 
> I understood that you were referring to download tank data from your DC but
> I use only a stupid BT and I would like to be in full control of my
> cylinder data.

Yes. So tell us in small words and short sentences ( :-) ) what it is that
you would like and what the various bugs and missing features are.

Ideally one at a time.

I'm not trying to be funny - but it's really really hard to debug this /
write the code when you don't quite understand what's wrong. 

For the developers usually the way we use things work. Otherwise we'd fix
it :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 12:04:03PM -0400, John Van Ostrand wrote:
> On Fri, Oct 31, 2014 at 10:45 AM, Dirk Hohndel  wrote:
> 
> > On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote:
> > > I was getting very frustrated adding a dive location to an existing
> > dive. I
> > > was expecting to be able to add a location then select the coordinates
> > from
> > > the globe and have the coordinates updated and the location name and
> > > coordinates associated. Neither happens. The flag is planted without text
> > > and the flag disappears when I save.
> >
> > That's not how it's supposed to work :-(
> 
> It's not supposed to work the way I expected or the way it does?

flag should disappear when you save.

> > > So I'm looking for ideas on proper behaviour. There are several
> > > circumstances I can think of:
> > >
> > > 1. User is adding a dive.. Associate the location with the edit location
> > > name of the dive.
> > > 2. User is editing an existing dive. Associate the location with the edit
> > > location name of the dive.
> >
> > I don't know what you mean by "edit location name of the dive" in both of
> > these cases.
> 
> I've looked at the code so I can write a little more concisely about it.
> 
> 1 and 2. When adding or editing a dive dive double clicking on the globe
> should add coordinates to the Coordinates field and place a marker on the
> globe so the user can see that he selected appropriate coordinates *before
> saving*. Neither happens, right now the action has no effect on the dive.

Bug. Needs to be fixed.
Sadly, this used to work :-(

> I've been able to make changes so the ui.coordinates field is updated but
> placing flags on the globe is more challenging. Since the edited location
> name and coordinates only exist in the ui.location and ui.coordinates
> variables the globe::repopulateLabels() function can't place a flag on the
> globe, repopulateLabels() uses the dive list for coordinates and labels.
> Adding code so it also checks isEditing() and places a flag based on the
> edited fields would add that functionality.

It should use the data from displayed_dive in addition to the dive list.
Then all you need to do is make sure things are tracked correctly in
displayed_dive (and they should, if not, that's yet another bug).

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 11:39:27AM -0400, John Van Ostrand wrote:
> 
> Mentioning Undo got me thinking.
> 
> I've been mucking about trying to have globe.cpp both update the editted
> dive *and* show the currently edit's placemark planted on the globe and the
> code is uglier than I like. The idea of "undo" has me thinking of ways to
> streamline that code and remove some oddities in the UI.

He.

> How about this.
> 
> When editing dives we update the dive on each field change, storing the old
> dive in an undo stack. We can accumulate similar consecutive edits to
> reduce the number of undos.

OK. That seems simple. Except when editing multiple dives. Then it gets...
interesting. But I'll go with the idea.

> This could include gas changes, events and even changes to the profile.

Yep, I can see that.

> Manually added dives can be done like this too.

You lost me.

> This would have a few benefits
> 
> 1. We eliminate the "This dive is being edited" indicator and all the code
> referencing "isEditing()".

So this is easy to write in text, but once you deal with the widgets it
gets a little tricky.

Example. You edit something (let's say a tag), your cursor is still in
that field, and then click on a different dive in the dive list. What
happens? You have a drop down open (date, cylinder type) and you change to
a different dive...

What I'm trying to say is that the definition of "I'm editing something"
is very intuitive, until you try to implement the finer details.

> 2. We don't have anything funny to do with placemarks on the map.
> 3. Oops, like accidental double clicks can be backed out.
> 4. Eliminate non-intuitive location/placemark functionality.
> 5. Any for_each_dive will automatically include the dive being edited so UI
> updates like placemarks don't need special cases.

That last one doesn't make sense to me. Can you elaborate.

> There would be a few challenges:
> 
> 1. Single dive edits would be easy but multi-dive edits would more
> complicated. They should be associated as one undo.

OK

> 2. Trips would be another undo case.

What does that mean? You mean trip changes to the divelist?
Uhhh, I want to see the data structure in which you do that :-)

> 3. We'd still have the issue of accidental edits, like an accidental
> double-click on the globe.
> 4. Other cases: Deletes, renumber, photo add/delete, imports, copy and
> paste, undos (i.e. redo)

Several of those would be crazy complicated to keep undo information
about. Renumbers for example. We need to draw the line somewhere.

> 5. Future changes will create more cases.
> 6. Edited dives may appear incomplete in the dive list.

What do you mean here?

> To implement:
> 
> 1. Create a structure for an undo that supports the known cases. Each
> struct is an atomic undo, an array of them is the undo stack. Maybe a
> complementary redo stack can be done too.

OK. See above. I'd like to see the data structures that you have in mind
here.

> 2. Determine what actions should accumulate into an atomic undo. (e.g.
> per-field undo or entire dive undo.)

I'd go with a dive undo. But once again - what does that mean in the
context of multi dive edits?

> 2. Create an undo function for each case.
> 3. Alter edits to directly change dive_list.

Please explain more.

> I've never done something like this before so I'm not sure if there are
> some really sneaky details lurking out of sight.

I promise, there are a MOUNTAIN of snarky details... But I like the basic
idea. Let's start drilling down on some details and see where we get.

All this is post 4.3, though.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: messing with the gas / tank handling

[Davide DB]

 If I correctly understand this topic, its' about the same old rant about
cylinder  management...

I hope this could be solved in 4.4 at least.
I'm editing multiple technical dives after a week of training and it's a
nightmare between bugs and missing functionalities.
While testing bugs 753 and 754 I realized that some dives have the "current
cylinder in use" PITA on all of them.
Actually I do not understand why in a row of six imported dives just a
couple of them have this problem on all cylinders.

- I never touched profiles
- I played with copy & paste on multiple tanks and god knows what happened.

I understood that you were referring to download tank data from your DC but
I use only a stupid BT and I would like to be in full control of my
cylinder data.

By
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 10:45 AM, Dirk Hohndel  wrote:

> On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote:
> > I was getting very frustrated adding a dive location to an existing
> dive. I
> > was expecting to be able to add a location then select the coordinates
> from
> > the globe and have the coordinates updated and the location name and
> > coordinates associated. Neither happens. The flag is planted without text
> > and the flag disappears when I save.
>
> That's not how it's supposed to work :-(
>

It's not supposed to work the way I expected or the way it does?


>
> > I thought that commit 9ead871d6456f8f19f6f0fe2413513ef4449253d was the
> > culprit except reverting it seemingly made no difference.
> > (qt-ui/globe.cpp:135 is the effective area of that commit.)
> >
> > So I added a dive to see what functionality that commit was supposed to
> > correct. By double clicking, the coordinates are associated with the
> > location of the highlighted dive in the dive list. I can see why that's
> bad.
> >
> > Then restoring the commit gave me the same add-dive bug, odd but I'll
> > forget about that right now.
>
> You lost me.
>

It looked as if that patch may have fixed a bug while adding a dive but
created one while editing a dive. I tested but the edit-dive problem was
elsewhere and I couldn't see a difference in how add-dive worked so I'm not
sure what bug it's supposed to have fixed. I don't think that's important
right now though.


>
> > So I'm looking for ideas on proper behaviour. There are several
> > circumstances I can think of:
> >
> > 1. User is adding a dive.. Associate the location with the edit location
> > name of the dive.
> > 2. User is editing an existing dive. Associate the location with the edit
> > location name of the dive.
>
> I don't know what you mean by "edit location name of the dive" in both of
> these cases.
>

I've looked at the code so I can write a little more concisely about it.

1 and 2. When adding or editing a dive dive double clicking on the globe
should add coordinates to the Coordinates field and place a marker on the
globe so the user can see that he selected appropriate coordinates *before
saving*. Neither happens, right now the action has no effect on the dive.

I've been able to make changes so the ui.coordinates field is updated but
placing flags on the globe is more challenging. Since the edited location
name and coordinates only exist in the ui.location and ui.coordinates
variables the globe::repopulateLabels() function can't place a flag on the
globe, repopulateLabels() uses the dive list for coordinates and labels.
Adding code so it also checks isEditing() and places a flag based on the
edited fields would add that functionality.

I had assumed a list associating location names and coordinates was kept
which is why I wrote "associate the location [i.e. coordinates] with the
location name."


> > 3. User is not editing a dive. Associate the location with the recorded
> > location name of the dive.
>

Circumstance 3 works as expected.


> Yep.
>
> > The problem arises that if the user changes the location while editing,
> or
> > cancels the edit that needs to change the location-coordinate mapping.
>
> Sorry, your language is just too confusing for me. There are three things
> that we need to treat separately:
> - location name
> - coordinates
> - flag placement on the globe
>
> Can you rephrase your three cases and your issue using these terms? Then
> we can determine which scenario isn't working right and hopefully fix
> it...
>
> > So, do we track that in the edit session and update it on a name change
> or
> > revert it on cancel?
> >
> > Or do we inform the user, on a double click, that they need to save
> first?
>
> So this is the one part I did understand. And I responded to THAT in my
> previous email.
>
> /D
>



-- 
John Van Ostrand
At large on sabbatical
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Copy and paste and multiple edit [was Proxy bug]

[Davide DB]

http://trac.subsurface-divelog.org/ticket/754#ticket

https://www.screenr.com/FaDN

On Fri, Oct 31, 2014 at 4:40 PM, Davide DB  wrote:

> Done
>
> https://www.screenr.com/RaDN
>
>
> http://trac.subsurface-divelog.org/ticket/753
>
> On Fri, Oct 31, 2014 at 4:04 PM, Davide DB  wrote:
>
>> On Fri, Oct 31, 2014 at 3:56 PM, Dirk Hohndel  wrote:
>>
>>>
>>> Please do. I guess I can think of a reason for this... it's possible that
>>> we only get the password when the Object is created and don't refresh it
>>> from the preferences when we try again. I'll look into that.
>>>
>>>
>> http://trac.subsurface-divelog.org/ticket/752
>>
>>
>> I'm trying to speed up editing operation through the mythical copy &
>> paste operation but I'm having hard times...
>> Now it seems that also editing gas in one tank used in multiple dives
>> doesn't work anymore :(
>>
>> I'll try to reproduce it capturing a video.
>>
>>
>>
>> --
>> Davide
>> https://vimeo.com/bocio/videos
>>
>
>
>
> --
> Davide
> https://vimeo.com/bocio/videos
>



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[John Van Ostrand]

On Fri, Oct 31, 2014 at 10:41 AM, Dirk Hohndel  wrote:

> On Fri, Oct 31, 2014 at 02:51:39PM +0100, Davide DB wrote:
> > On Thu, Oct 30, 2014 at 9:22 PM, John Van Ostrand 
> > wrote:
> >
> > > So, do we track that in the edit session and update it on a name
> change or
> > > revert it on cancel?
> > >
> > > Or do we inform the user, on a double click, that they need to save
> first?
> >
> > Good question.
> > Actually I always found the editing/saving process very inconsistent.
> > Why I get "dive is being edited" alert just on the "dive notes" tab but I
> > can change tanks, I can add events on the profile without any alert?
>
> Just to be precise, you cannot modify equipment without triggering the
> "edit mode". But you can add a gas change.
>
> Yes, our handling of edits is extremely inconsistent. It has bugged me for
> a long time.
>
> I absolutely want a way to say "never mind" when editing things. I usually
> need that in the context of edits to the info page, so that's where it got
> implemented. But then there are several other ways to edit things where we
> don't have that.
>
> People have suggested an undo/redo feature but that would be an even more
> complex layer to add.
>
> Today you can make changes in these places (I hope I didn't forget any)
>
> 1) Dive notes tab (date, time, location, divemaster, buddy, tags, notes)
>   (and once you entered edit mode, on a manually added dive, you can
>   change the profile in the profile, but you can only start this process
>   if you actually change some other field first - that's completely
>   broken)
>   Equipment tab (tanks and weights).
>
> The moment you edit things in Dive notes or Equipment tab, this triggers
> "edit mode" and the "save / discard" functionality.
>
> 2) Right click on the profile (changing/adding/removing events, gas
>   changes, order of dive computers, delete dive computer
>
> All of these take immediate effect
>
> 3) Double click on the globe window
>
> Also takes immediate effect
>
> 4) Dive list (mostly changes to trip status, but also delete dives or shift
>   their times)
>
> All of these take immediate effect
>
>
> I think it would be fairly simple to switch to edit mode when making
> changes in the second and third case above. Not sure this can be
> reasonably done in the last one. Or we could do what other software does
> and not have this edit mode. So basically the moment you tab away from a
> field that edit is permanent. Only if you use ESC is an edit reverted.
>
> I'll admit that I'd hate that, so I'd be more inclined to got with adding
> edit mode to 2) and 3) above.
>
> Comments? Preferences


Mentioning Undo got me thinking.

I've been mucking about trying to have globe.cpp both update the editted
dive *and* show the currently edit's placemark planted on the globe and the
code is uglier than I like. The idea of "undo" has me thinking of ways to
streamline that code and remove some oddities in the UI.

How about this.

When editing dives we update the dive on each field change, storing the old
dive in an undo stack. We can accumulate similar consecutive edits to
reduce the number of undos.
This could include gas changes, events and even changes to the profile.
Manually added dives can be done like this too.

This would have a few benefits

1. We eliminate the "This dive is being edited" indicator and all the code
referencing "isEditing()".
2. We don't have anything funny to do with placemarks on the map.
3. Oops, like accidental double clicks can be backed out.
4. Eliminate non-intuitive location/placemark functionality.
5. Any for_each_dive will automatically include the dive being edited so UI
updates like placemarks don't need special cases.

There would be a few challenges:

1. Single dive edits would be easy but multi-dive edits would more
complicated. They should be associated as one undo.
2. Trips would be another undo case.
3. We'd still have the issue of accidental edits, like an accidental
double-click on the globe.
4. Other cases: Deletes, renumber, photo add/delete, imports, copy and
paste, undos (i.e. redo)
5. Future changes will create more cases.
6. Edited dives may appear incomplete in the dive list.


To implement:

1. Create a structure for an undo that supports the known cases. Each
struct is an atomic undo, an array of them is the undo stack. Maybe a
complementary redo stack can be done too.
2. Determine what actions should accumulate into an atomic undo. (e.g.
per-field undo or entire dive undo.)
2. Create an undo function for each case.
3. Alter edits to directly change dive_list.


I've never done something like this before so I'm not sure if there are
some really sneaky details lurking out of sight.

-- 
John Van Ostrand
At large on sabbatical
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Proxy bug [was Re: Setting location coordinates while editing a dive]

[Davide DB]

Done

https://www.screenr.com/RaDN


http://trac.subsurface-divelog.org/ticket/753

On Fri, Oct 31, 2014 at 4:04 PM, Davide DB  wrote:

> On Fri, Oct 31, 2014 at 3:56 PM, Dirk Hohndel  wrote:
>
>>
>> Please do. I guess I can think of a reason for this... it's possible that
>> we only get the password when the Object is created and don't refresh it
>> from the preferences when we try again. I'll look into that.
>>
>>
> http://trac.subsurface-divelog.org/ticket/752
>
>
> I'm trying to speed up editing operation through the mythical copy & paste
> operation but I'm having hard times...
> Now it seems that also editing gas in one tank used in multiple dives
> doesn't work anymore :(
>
> I'll try to reproduce it capturing a video.
>
>
>
> --
> Davide
> https://vimeo.com/bocio/videos
>



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Proxy bug [was Re: Setting location coordinates while editing a dive]

[Davide DB]

On Fri, Oct 31, 2014 at 3:56 PM, Dirk Hohndel  wrote:

>
> Please do. I guess I can think of a reason for this... it's possible that
> we only get the password when the Object is created and don't refresh it
> from the preferences when we try again. I'll look into that.
>
>
http://trac.subsurface-divelog.org/ticket/752


I'm trying to speed up editing operation through the mythical copy & paste
operation but I'm having hard times...
Now it seems that also editing gas in one tank used in multiple dives
doesn't work anymore :(

I'll try to reproduce it capturing a video.



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Proxy bug [was Re: Setting location coordinates while editing a dive]

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 03:50:04PM +0100, Davide DB wrote:
> 
> I'm just editing my last dives and I found a bug on Proxy:
> 
> - Proxy password has expired
> - You try to download GPS point and you get "authentication error"
> - You update the password and save new setting but the new password is not
> used by the GPS download feature but it was correctly saved.
> - Restart the application, everything works.
> 
> I'll file a bug on trac

Please do. I guess I can think of a reason for this... it's possible that
we only get the password when the Object is created and don't refresh it
from the preferences when we try again. I'll look into that.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Davide DB]

On Fri, Oct 31, 2014 at 3:41 PM, Dirk Hohndel  wrote:

>
> I'll admit that I'd hate that, so I'd be more inclined to got with adding
> edit mode to 2) and 3) above.
>
> Comments? Preferences?
>
> /D
>

+1

PS

I'm just editing my last dives and I found a bug on Proxy:

- Proxy password has expired
- You try to download GPS point and you get "authentication error"
- You update the password and save new setting but the new password is not
used by the GPS download feature but it was correctly saved.
- Restart the application, everything works.

I'll file a bug on trac



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Thu, Oct 30, 2014 at 04:22:03PM -0400, John Van Ostrand wrote:
> I was getting very frustrated adding a dive location to an existing dive. I
> was expecting to be able to add a location then select the coordinates from
> the globe and have the coordinates updated and the location name and
> coordinates associated. Neither happens. The flag is planted without text
> and the flag disappears when I save.

That's not how it's supposed to work :-(

> I thought that commit 9ead871d6456f8f19f6f0fe2413513ef4449253d was the
> culprit except reverting it seemingly made no difference.
> (qt-ui/globe.cpp:135 is the effective area of that commit.)
> 
> So I added a dive to see what functionality that commit was supposed to
> correct. By double clicking, the coordinates are associated with the
> location of the highlighted dive in the dive list. I can see why that's bad.
> 
> Then restoring the commit gave me the same add-dive bug, odd but I'll
> forget about that right now.

You lost me.

> So I'm looking for ideas on proper behaviour. There are several
> circumstances I can think of:
> 
> 1. User is adding a dive.. Associate the location with the edit location
> name of the dive.
> 2. User is editing an existing dive. Associate the location with the edit
> location name of the dive.

I don't know what you mean by "edit location name of the dive" in both of
these cases.

> 3. User is not editing a dive. Associate the location with the recorded
> location name of the dive.

Yep.

> The problem arises that if the user changes the location while editing, or
> cancels the edit that needs to change the location-coordinate mapping.

Sorry, your language is just too confusing for me. There are three things
that we need to treat separately:
- location name
- coordinates
- flag placement on the globe

Can you rephrase your three cases and your issue using these terms? Then
we can determine which scenario isn't working right and hopefully fix
it...

> So, do we track that in the edit session and update it on a name change or
> revert it on cancel?
> 
> Or do we inform the user, on a double click, that they need to save first?

So this is the one part I did understand. And I responded to THAT in my
previous email.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 02:51:39PM +0100, Davide DB wrote:
> On Thu, Oct 30, 2014 at 9:22 PM, John Van Ostrand 
> wrote:
> 
> > So, do we track that in the edit session and update it on a name change or
> > revert it on cancel?
> >
> > Or do we inform the user, on a double click, that they need to save first?
> 
> Good question.
> Actually I always found the editing/saving process very inconsistent.
> Why I get "dive is being edited" alert just on the "dive notes" tab but I
> can change tanks, I can add events on the profile without any alert?

Just to be precise, you cannot modify equipment without triggering the
"edit mode". But you can add a gas change.

Yes, our handling of edits is extremely inconsistent. It has bugged me for
a long time.

I absolutely want a way to say "never mind" when editing things. I usually
need that in the context of edits to the info page, so that's where it got
implemented. But then there are several other ways to edit things where we
don't have that.

People have suggested an undo/redo feature but that would be an even more
complex layer to add.

Today you can make changes in these places (I hope I didn't forget any)

1) Dive notes tab (date, time, location, divemaster, buddy, tags, notes)
  (and once you entered edit mode, on a manually added dive, you can
  change the profile in the profile, but you can only start this process
  if you actually change some other field first - that's completely
  broken)
  Equipment tab (tanks and weights).

The moment you edit things in Dive notes or Equipment tab, this triggers
"edit mode" and the "save / discard" functionality.

2) Right click on the profile (changing/adding/removing events, gas
  changes, order of dive computers, delete dive computer

All of these take immediate effect

3) Double click on the globe window

Also takes immediate effect

4) Dive list (mostly changes to trip status, but also delete dives or shift
  their times)

All of these take immediate effect


I think it would be fairly simple to switch to edit mode when making
changes in the second and third case above. Not sure this can be
reasonably done in the last one. Or we could do what other software does
and not have this edit mode. So basically the moment you tab away from a
field that edit is permanent. Only if you use ESC is an edit reverted.

I'll admit that I'd hate that, so I'd be more inclined to got with adding
edit mode to 2) and 3) above.

Comments? Preferences?

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Correct bug: setpoint handling of Poseidon CCR dive logs

[Dirk Hohndel]

On Fri, Oct 31, 2014 at 08:30:14AM +0200, Willem Ferguson wrote:
> For this reason neither the temperature data nor the oxygen-related data
> need to be zeroed since the resolution of all these variables is more than
> sufficient and is highly unlikely to cause a blocky type of graph on the
> profile as long as these variable are logged fairly regularly. With the
> present code there is no possibility of interpolation of these data anyway.
> As an aside, temperature data from my Uwatec dive computer is blocky but
> this is because of the lack of temperature resolution of the DC. My Mares DC
> has better temperature resolution and a smooth temperature profile.
> 
> Therefore, would it be sensible if I removed the zeroing out of
> oxygen-related and temperature data, more or less as described in the plan
> of action above?

Yes, I think so.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Setting location coordinates while editing a dive

[Davide DB]

On Thu, Oct 30, 2014 at 9:22 PM, John Van Ostrand 
wrote:

> So, do we track that in the edit session and update it on a name change or
> revert it on cancel?
>
> Or do we inform the user, on a double click, that they need to save first?
>
>


Good question.
Actually I always found the editing/saving process very inconsistent.
Why I get "dive is being edited" alert just on the "dive notes" tab but I
can change tanks, I can add events on the profile without any alert?

Regarding your question, we should inform the user I guess.


-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface