Re: help understanding a Windows crash report

[Lubomir I. Ivanov]

On 30 October 2014 00:07, Dirk Hohndel d...@hohndel.org wrote:

 Please test
 http://subsurface-divelog.org/downloads/daily/subsurface-4.2-349-g2b8043b82b99.exe
 if you have a chance to make sure that it's not just my system where this
 works again...

 This one also implements the long missing don't install 64bit binaries on
 a 32bit system feature...


quickly tested the installer and there are no crashes.

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

Re: help understanding a Windows crash report

[Dirk Hohndel]

 On Oct 30, 2014, at 3:15 AM, Lubomir I. Ivanov neolit...@gmail.com wrote:
 
 On 30 October 2014 00:07, Dirk Hohndel d...@hohndel.org wrote:
 
 Please test
 http://subsurface-divelog.org/downloads/daily/subsurface-4.2-349-g2b8043b82b99.exe
 if you have a chance to make sure that it's not just my system where this
 works again...
 
 This one also implements the long missing don't install 64bit binaries on
 a 32bit system feature...
 
 
 quickly tested the installer and there are no crashes.

Good. Thanks.

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

[PATCH] Added close button to print preview window title bar.

[John Van Ostrand]

Without this I was only able to close it by choosing to print.

Signed-off-by: John Van Ostrand j...@vanostrand.com
---
 qt-ui/printdialog.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/qt-ui/printdialog.cpp b/qt-ui/printdialog.cpp
index f8f06ae..a65078b 100644
--- a/qt-ui/printdialog.cpp
+++ b/qt-ui/printdialog.cpp
@@ -68,7 +68,10 @@ PrintDialog::PrintDialog(QWidget *parent, Qt::WindowFlags f) 
: QDialog(parent, f
 
 void PrintDialog::previewClicked(void)
 {
-   QPrintPreviewDialog previewDialog(printer, this);
+   QPrintPreviewDialog previewDialog(printer, this, Qt::Window
+   | Qt::CustomizeWindowHint | Qt::WindowCloseButtonHint
+   | Qt::WindowTitleHint);
+
connect(previewDialog, SIGNAL(paintRequested(QPrinter *)), this, 
SLOT(onPaintRequested(QPrinter *)));
previewDialog.exec();
 }
-- 
1.8.3.1

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

Re: messing with the gas / tank handling

[Steve Butler]

G  Once my EON Steel arrives we'll need to drive up to Hoodsport and do 
some data collection... :-)?


As in Hood Canal, WA?  Somehow I thought you were located in Europe.  
Guess I need to be more curious in the future!


--Steve (Enumclaw, WA -- OC mostly at Redondo)

PS  Looks like I'll need to pick up a modern language like C to add to 
my ancient language list (COBOL, Fortran, PL/SQL, etc).  Become more 
useful here.



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

divelist and units

[Dirk Hohndel]

So someone suggested this idea the other day (sorry, forgot who it was)
when we were discussing the space issues and alignment issues with the
header of the divelist. Don't show the units in the header at all, show
them only in a tooltip. So I figured how hard can that be? and tried to
implement it this morning. Surprisingly, it was ridiculously easy.

This Qt thing might be working out for us after all...

:-)

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

Re: totally off topic [was: Re: messing with the gas / tank handling]

[John Van Ostrand]

On Thu, Oct 30, 2014 at 10:57 AM, Dirk Hohndel d...@hohndel.org wrote:

 On Thu, Oct 30, 2014 at 07:45:47AM -0700, Steve Butler wrote:
  G  Once my EON Steel arrives we'll need to drive up to Hoodsport and do
  some data collection... :-)?
 
  As in Hood Canal, WA?  Somehow I thought you were located in Europe.
 Guess
  I need to be more curious in the future!

 Hehe. Linus, Thiago and I all three live in Portland, OR. But we're
 originally from Finland, Brazil, and Germany, respectively.

 I did almost all my dive training in Hoodsport, WA and occasionally
 pretend to work there as a dive master or tec dive master. And as much as
 I enjoy warm water diving, there is no warm water anywhere in driving
 distance, so if I need to collect data, I drive up to Hoodsport -
 especially for things like multi-cylinder diving or deco diving.

 But since we are entirely off topic already... John Hawley, a coworker of
 mine at Intel, is currently building the Auto Diver. A contraption that
 will allow us to automatically lower and raise a dive computer into a
 pool... which makes it possible to add a lot of really boring dives to a
 dive computer (for cases where we are concerned with things that happen
 once there are tons of dives on a DC, e.g. for the EON Steel where we
 don't know what will happen to its directory entries).


Some of the tests I want to see on a dive computer involve volume of data
and also depths. For volume I need to exceed the enormous limits of Cochran
computers, like 1450 hours of sample data and 1024 logged dives. For depth
I need to exceed 256 ft to verify how the data is encoded. I'm neither
trained nor comfortable doing a dive like that.

The LDS had cut the bottom 12 off an old AL80 and had a machine shop
modify it to be a pressure chamber, add water and it's a dive simulator.
It's manual, in that the user presses a valve to add compressed air and
turns a bleed screw to release. Unfortunately it maxed out at 150ft and far
too manual to do 1000 dives. However add some solenoids and maybe it could
be automated.


  --Steve (Enumclaw, WA -- OC mostly at Redondo)

 So you're 60 miles closer to Hoodsport than we are :-)

  PS  Looks like I'll need to pick up a modern language like C to add to my
  ancient language list (COBOL, Fortran, PL/SQL, etc).  Become more useful
  here.

 Yes, please. Especially, please pick up C++ and focus on Qt development.
 That's the number 1 area where we need more active contributors :-)

 After your tenth UI related patch I'll invite you to a dive weekend at the
 Yellow House (only partly kidding).

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




-- 
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: divelist and units

[Dirk Hohndel]

On Thu, Oct 30, 2014 at 11:25:25AM -0400, John Van Ostrand wrote:
 On Thu, Oct 30, 2014 at 11:10 AM, Dirk Hohndel d...@hohndel.org wrote:
 
  So someone suggested this idea the other day (sorry, forgot who it was)
 
 It was in trac where I made the suggestion. I'm glad it worked out, since I
 really don't know what I'm doing..

Thanks for the idea...

 John Van Ostrand
 At large on sabbatical

Oh, so you have time to learn Qt and contribute even more! Awesome :-)

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

Re: help understanding a Windows crash report

[Dirk Hohndel]

On Wed, Oct 29, 2014 at 09:19:22PM -0700, Dirk Hohndel wrote:
 
  On Oct 29, 2014, at 6:50 PM, Thiago Macieira thi...@macieira.org wrote:
  
  I'm fairly certain it's not a Qt bug now. This is a binary incompatibility 
  issue between QtGui and QtWidgets due either a bug in Dirk's packaging or 
  in 
  Fedora's packaging.
  
  Dirk: verify that the DLLs you gave me are exactly the ones that Fedora 
  shipped. If they are, the bug is in Fedora's build, somehow. It looks like 
  a 
  stale Qt5Gui.dll got packaged instead of the right one.
 
 I am 99% certain that the package I gave you had the correct DLLs from the
 Fedora packages. I’ll need to hunt down the md5 values for those DLLs to be
 100% sure.

I am now certain that I am packaging the Qt DLLs as delivered by Fedora 20.
I uninstalled the corresponding packages, reinstalled them from the server
and compared md5 fingerprints of all the Qt DLLs with the ones from the
DLLs that were in the package that crashed...

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

Re: divelist and units

[Linus Torvalds]

On Thu, Oct 30, 2014 at 8:10 AM, Dirk Hohndel d...@hohndel.org wrote:
 So someone suggested this idea the other day (sorry, forgot who it was)
 when we were discussing the space issues and alignment issues with the
 header of the divelist. Don't show the units in the header at all, show
 them only in a tooltip. So I figured how hard can that be? and tried to
 implement it this morning. Surprisingly, it was ridiculously easy.

Nice. Me like.

And it reminded me of another issue - don't bother showing dive
duration in seconds. Patch attached.

NOTE! If we really have freedivers who use subsurface to log their
freediving, maybe this needs to be some kind of setting. I don't know.

 Linus
From c3681f9e9d7b11dfc9482ccb417bba81fae4e700 Mon Sep 17 00:00:00 2001
From: Linus Torvalds torva...@linux-foundation.org
Date: Thu, 30 Oct 2014 09:49:05 -0700
Subject: [PATCH] Display dive duration in dive list in whole minutes

The whole duration in seconds is being way too OCD about the
information, and just makes it harder to read.

Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
 qt-ui/models.cpp | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
index 1e41dc173df0..bf1c6a6deb62 100644
--- a/qt-ui/models.cpp
+++ b/qt-ui/models.cpp
@@ -1324,19 +1324,17 @@ QString DiveItem::displayDepthWithUnit() const
 
 QString DiveItem::displayDuration() const
 {
-	int hrs, mins, secs;
+	int hrs, mins;
 	struct dive *dive = get_dive_by_uniq_id(diveId);
-	secs = dive-duration.seconds % 60;
-	mins = dive-duration.seconds / 60;
+	mins = (dive-duration.seconds+59) / 60;
 	hrs = mins / 60;
 	mins -= hrs * 60;
 
 	QString displayTime;
 	if (hrs)
-		displayTime = QString(%1:%2:).arg(hrs).arg(mins, 2, 10, QChar('0'));
+		displayTime = QString(%1:%2).arg(hrs).arg(mins, 2, 10, QChar('0'));
 	else
-		displayTime = QString(%1:).arg(mins);
-	displayTime += QString(%1).arg(secs, 2, 10, QChar('0'));
+		displayTime = QString(%1).arg(mins);
 	return displayTime;
 }
 
-- 
2.1.2.452.gd5ca7ae

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

Re: [PATCH] Divelist: make the column headers for units left aligned

[Dirk Hohndel]

Just FYI, I had this applied yesterday and then reverted it today because
I think with my change to move the units to the tooltip I think this isn't
needed and things actually look better without it.

I know you implemented what I suggested. Thanks for that. It's just that
John's suggestion was better than mine :-)

/D

On Wed, Oct 29, 2014 at 06:23:25PM +0200, Lubomir I. Ivanov wrote:
 From: Lubomir I. Ivanov neolit...@gmail.com
 
 Fixes #739
 
 Signed-off-by: Lubomir I. Ivanov neolit...@gmail.com
 ---
  qt-ui/models.cpp | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/qt-ui/models.cpp b/qt-ui/models.cpp
 index ef76e7e..f548d37 100644
 --- a/qt-ui/models.cpp
 +++ b/qt-ui/models.cpp
 @@ -1081,7 +1081,7 @@ static int nitrox_sort_value(struct dive *dive)
   return he * 1000 + o2;
  }
  
 -static QVariant dive_table_alignment(int column)
 +static QVariant dive_table_alignment(int column, bool isHeader)
  {
   QVariant retVal;
   switch (column) {
 @@ -1093,7 +1093,7 @@ static QVariant dive_table_alignment(int column)
   case DiveTripModel::OTU:
   case DiveTripModel::MAXCNS:
   // Right align numeric columns
 - retVal = int(Qt::AlignRight | Qt::AlignVCenter);
 + retVal = int((isHeader ? Qt::AlignLeft : Qt::AlignRight) | 
 Qt::AlignVCenter);
   break;
   // NR needs to be left aligned becase its the indent marker for trips 
 too
   case DiveTripModel::NR:
 @@ -1116,7 +1116,7 @@ QVariant DiveItem::data(int column, int role) const
  
   switch (role) {
   case Qt::TextAlignmentRole:
 - retVal = dive_table_alignment(column);
 + retVal = dive_table_alignment(column, false);
   break;
   case DiveTripModel::SORT_ROLE:
   Q_ASSERT(dive != NULL);
 @@ -1353,7 +1353,7 @@ QVariant DiveTripModel::headerData(int section, 
 Qt::Orientation orientation, int
  
   switch (role) {
   case Qt::TextAlignmentRole:
 - ret = dive_table_alignment(section);
 + ret = dive_table_alignment(section, true);
   break;
   case Qt::FontRole:
   ret = defaultModelFont();
 -- 
 1.7.11.msysgit.0
 
 ___
 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] Correct bug: setpoint handling of Poseidon CCR dive logs

[Dirk Hohndel]

Linus,

much of this is code that you wrote (the original when do we zero thing,
when don't we). I clearly mis-remembered some of this. Would you chime in
to get to the right resolution here, please?

On Thu, Oct 30, 2014 at 08:29:18AM +0200, Willem Ferguson wrote:
 Ok, so here is how I understand the code as it is at present. It all happens
 in
 fixup_dive_dc() in dive.c and in fill_o2_values in profile.c.
 
 fixup_dive_dc():
 
 While a particular cylinder is being used (i.e. while the index of the
 cylinder *remains the same*), the duplicate gas pressure values are zeroed
 out. This is pre-existing code, i.e  it was there before any CCR code was
 developed. I only added the zeroing out for diluent gas pressures as well.
 [~line 1138 in dive.c].

I think I remember now. The logic was that many tank sensors don't give a
reading in every sample. And somehow, somewhere this got converted into
samples with no pressure reading ending up with the previous pressure
reading which gave rather step function looking plots. 

 The pre-existing code also zeroed out duplicate temperature values [~line
 1169]. You can see there that the style of the commenting for that
 particular operation is different from my style of commenting.

Same logic I believe.

 Immediately below the temperature value manipulation I added code that
 zeroes out the oxygen-related data. (o2 sensors and o2 setpoint).

And at least for O2 setpoint that's problematic, given that we use this to
distinguish CCR and OC. Maybe that's wrong and we need to fix THAT
elsewhere, but right now that's what we do.

 Now where do all the zeroed data values get re-instated for profile
 calculations? As follows:
 
 1) Gas pressures:
 In gaspressures.c the zeroed gas pressure values effectively get replaced.
 This is code that originally comes from profile.c and that code does *much*
 more than just re-instating the zeroed values. But, amongst others,
 interpolated values (using raw data from structures of sample) replace
 zeroed values in the appropriate places in structures of plotdata.

Yes, it does smart interpolation (depth based, attempting constant SAC
rate) and removes linear interpolation (some dive log programs did that
and filled in these completely ridiculous linear interpolations... we
detect that and rip it out).

 2) Temperature values:
 The temperature values are re-instated in populate_plot_entries() in
 profile.c (~line 591). This is pre-existing code.
 
 3) Oxygen values:
 In function fill_o2_values() in profile.c the zeroed sensor data and
 setpoint data are re-instated for plotting. As with the pressure
 calculations mentioned above, this function does more than re-instating
 zeroed oxygen values. It also triggers calculation of po2 values that are
 stored in pressures.o2 contained within each structure of plotdata.

This is the code I'm less familiar with - that's partly yours (Willem),
partly Robert's, I think.

 Towards a plan of action:
 In the underlying data structures the memory space requirements are the
 same, regardless of whether a zero is stored in a location or a measured
 data value. My suggestion is that we do not touch the pressure values in
 fixup_dive_dc but that we remove code  that zeroes the oxygen-related
 values. Similarly, fill_o2_values() in profile.c is reduced to a loop that
 steps through the structures of plotdata, which corrects zero values (that
 might have originated either from the insertion of events along the dive
 profile or from glitches in the logging or download process) and which
 triggers po2 calculation for each structure of plotdata (i.e. each point on
 the dive profile).

That sounds sane.

 I am not sure what to do about the zeroing and re-instatement of temperature
 data but if we were consistent, the zeroing of temperature data should also
 be removed.

Why? Can you explain why the tank pressure handling would stay, but the
temperature handling would change?

/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

[Linus Torvalds]

On Thu, Oct 30, 2014 at 10:32 AM, Dirk Hohndel d...@hohndel.org wrote:

 I think I remember now. The logic was that many tank sensors don't give a
 reading in every sample. And somehow, somewhere this got converted into
 samples with no pressure reading ending up with the previous pressure
 reading which gave rather step function looking plots.

Yeah, I think we did that to fix up the fact that we used to
originally populate samples with the previous sample data, and so to
correct old cases we'd clear duplicates, and do the much nicer
interpolation instead.

 The pre-existing code also zeroed out duplicate temperature values [~line
 1169]. You can see there that the style of the commenting for that
 particular operation is different from my style of commenting.

 Same logic I believe.

Yes, except I think for temperatures we don't clear out duplicates, we
clear out ranges (so we leave the end-points). But yes, same
situation.

 And at least for O2 setpoint that's problematic, given that we use this to
 distinguish CCR and OC. Maybe that's wrong and we need to fix THAT
 elsewhere, but right now that's what we do.

Yes, I think the O2 setpoints should not try to clear out duplicates,
since you'd *expect* things to be duplicate.

Of course, many of these things are then also tied into with
saving/loading issues. For example, O2 setpoints you would expect to
save only once, and not save for each sample, and then loading would
populate the subsequent ones with the previous value.

Which is what we used to incorrectly do for pressure data. But
cylinder pressure really is a sample once in a while, while
setpoints are set once and leave until it changes with no
interpolation.

Of course, then we have the question about things like O2 _sensor_
data as opposed to manually set setpoints. Should those be sample
once in a while and interpolate in between, or what?

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

Re: [PATCH] Changed tissue icon on profile graph.

[Dirk Hohndel]

On Thu, Oct 30, 2014 at 01:51:06PM -0400, John Van Ostrand wrote:
 The previous icon was of a bird that didn't seem to make sense. This
 icon looks like the tissue graph and should be more intuitive.

Yes. BTW, I think the bird is an inside joke. The idea for the graph was
inspired by the Shearwater Petrel...

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

[PATCH] Added English documentation for tissue graph.

[John Van Ostrand]

---
 Documentation/images/tissues.jpg  | Bin 0 - 1270 bytes
 Documentation/images/tissuesGraph.jpg | Bin 0 - 37994 bytes
 Documentation/user-manual.txt |   7 +++
 3 files changed, 7 insertions(+)
 create mode 100644 Documentation/images/tissues.jpg
 create mode 100644 Documentation/images/tissuesGraph.jpg

diff --git a/Documentation/images/tissues.jpg b/Documentation/images/tissues.jpg
new file mode 100644
index 
..bac1456f0d3185002c0b53148f82d5fe4470fb1f
GIT binary patch
literal 1270
zcmb7@drZ?;6vyxHRa*Ms_bb1a@))xvupv%TY84sK6-VdTf)=}h%UrBHrZ|^WKr41
zB8~u4Q;P#c6x8zQgbg(g77;_5-J8`7%HGh27^{sh{L%t290x*q=N1{#Y}pL5Rl
zT1OK2p|(wZs=;AYdarzQvu01QQ47X}V5!6XPACpko7)*{Qhr{+{v$;Gz$mWz
zHk%ZZls7F92smCoA|Wl}(*oKhf?)6sPOu1qMRVC)`hSPB3s6iD2m#L0w{%G6yod#
zz5t*Y0+t1eV+4ZQ+|jm^`9Jupg6BJ^o}1|=~P0AvCHzb=iX^=X{h!1;Y`df2!+
zF?Tqmv3hPO#CNn8ZK#^0ICI0EIJHriWlC4hV`*dkdf6J`(sHL+rD=jm@`eYg9$
zR=@uGRA@rnZRUdb5`5_#=^_b$}`(7Ct?BM8{14qHdQ215Y4T2#AYq19e1sKk!
zNIJq;yFx6HDwDLj$8H3~E0FsQREmO=S;Lo2a@CH82y2sG~=Vy;U({bzYs%c(G*@
z`O2yD0|J$$GH2WWXHWEed2CmrJDqp3~T}ACQ4x7E2(D2$F8m8IE^OyIH7)t3@}
zA)$10Iw!Xxbv)JPSLtutck)p5nev%3EA=C{+M3?ai+xvEUSGLMf7(lLy^!3j$V%HC
zD-_-Gk(XdoUMBAr`FtxSL@qN#ZeAwJJtfH6E4NqgGD4Z|$mPlnvElIE0VJI;D
zJ5YuKogQso_jlpr@d*13$pE?W*~OAy9J;oiht}D(bzhnGYYAl+$}nNB6wA0w?on^
zTc0FUZB0D4-Cmy)a@PZUl-qh!{?Q??Kjq#$zsO?SOhdkqHS-=hoy)~h(^KEG+-%|
zSV}6@Izy*%dS~?h4|WPJ?|YNBklY6%)PC3e?3La{?zNy=6gO`$56-dqapIKtBsG
z@_?}9nbz8r!_nHuBm3Qij~lu-JFS8f7sk~w-q8IG7FN3n~?E@|s$O3)FTYEX
z8j0H+99{GVz%_34Wv?MRBKy0mllBR8xr}N%9yG_v6vrCMoJ3`IzklMoXGGA)v7l|
zVTa?p!!K$Qeh}OW4sCuzQEZDIJ~C*2p|fxAt#7}dy1jUyLNGuYEr8+)OH$MmfR;t
zk{U|#R)ltcp!;n9rKy)WN9DS9*KS9$;uj5r5f4McPh_+HNl;Ye4ktl#|gYjuB=
z^=-G=gQ9k}#FuhVtoL)%FoU@+*--?^FO%?#xc|_C_wEjrYAvZV-dUVB`ElHX_Fp@q
zj;^fxqD{P`FZWNr0LAJRtIe_GJ~;$*KI7n+lU~)vhi#oe_w6DrFefoaZ8_Acv@
zJKF|wdy@6pUvpl+qYg8p6{woa{a~nLeip8+-2GXAYVbiHqOM5GDSw_KCA=R5EJ
E1O2U%4gdfE

literal 0
HcmV?d1

diff --git a/Documentation/images/tissuesGraph.jpg 
b/Documentation/images/tissuesGraph.jpg
new file mode 100644
index 
..8f5292fa1b95cc89f5816d81706e4c1ef2d6412b
GIT binary patch
literal 37994
zcmcG$1yr0(vM@YYaDoSScXxMpcXxM(5S-xd?hI}L0Rw|clQungZ$*(y?giG-TRU
zoS8#^y%vEs;;iC3OQ!=56V13xFmAuRy_0|Ns{y?+32s{l~|1UUGg@cux)2PhaQ
zC`dsIB4h(FbHr62=H+5@Q6sL$cRWNNbvB;n8+w-=olCn2pOTVWMN9qGO={VFCv6
zUI!8i777X$9T6T8{r~!Tjj{|0E{8*A;3@o;3!}aC}3~06YK~0370vxc_({Ai=)
zK0w2~V{zZh{~-Sf3kLq)gAdSeD*yzD_o~Pc$NJ?3+xmxvS{O9EKv3F|ALTdl0ttH
zVB|B?e-%i(x%~xkwZiKDN|3el03L612k~J5d?~p#m8pI$69rYxr4QmfAD|Me;!zd
z*q}cUT(6x4+JD09sLD4Jg3pN~pE36Sx=(HWt?AWcf%rnJNkqDV;+?*LLl!aS
z@n;tu-@0x6izr}_WkIO=6P4e@9-9}8CsN||LoB79QvNg;b@e!(ZPHmM57!W~b|xB1
z4I2Yrymzr9L)wUBSCNx$$o*r4n;HcrOB^Oo_+y#!^^;$BW9ziILu@hNT6NDy-MhB
zRtfxTCt||8gt+6@sDBCSNKf*Ka~E!9YY?ezmX{o`vLIA=YFw9g{M;Q+JF0qbUem
zOKi%z?zzfTP3~wFEu63viYwOa-i0{G~=Y}Yl9JJB)Bbnu8pYC%?jM}F-+m^a
zQBHzF@IF7A`LTC8*%F9zBX%z{hvx)1Pl64+dSJ4=2a^JhU%=C5rMHL9174~+Fg
zo3@qIzRr01}5!{(@u;JV5|3NrcYYjD5X@i$#K#muBjeXq_5w)hRl0ccAx7NbADg
zio88{`n7ILGt=QO4CZOncE+z+V~5T1tnz*L(uv6C6OjGwU+T+PSTZhZlOD^E=PA
zSs!gzH;VyG)l{AAApPi*UuLGNuInD%%oOnwwh+Vgt#zCn+k@X3DZq98C+)uwll
zEE~EX?-t$|$149zy1$PLsqt5{R7yvSy%d{)(~+*IIUpmKy+ndIX{KFkI$`U
zjmnB`1-hyf5a`~_$;ojYu%~iy_jX7NPXySsBrUIHT1Z_=d7=6av#=Q5Q{S54$ArU
zYgsdQ#lm=a*cqomW99=ED_fI7{!yXPs0*4MrdxUdeGm*y9WgVZNr*aWKb+ffQ
zFz?{HoV#7~oxXDUtk2*OuWV?zda5y{gb^s2TiQAz(8)v^#TQ{l2^O!jO^j*6sJy
z_=_h*%Qx=dk~P;1fBN-j+=B%v57CLjERf3dJL}PAkpMk1`y?eDVhuTP$9r_trxOz
z#l!)^-VJEEjhS((B|R!mC33VZkHvhF^9}XY_)R=fhb%}P8ZjY1{(V3qOCFm(Z_-E
zm8yI?E$rWIciGRAw{Z%iGkpyvJo_b*^hmurc}xa4VT0FzGq6vbj_P4O_didNZj
zEKZpp9Kvs|`a2rrt~0q^Pvq9w8%Syh_|D!w;$HYe_w=RBN;e#bMtp~ZwLr3Q~?82
zZ}jv7bg$_@b91iy|(kTy!YyZJD7?Gn$1@6;H!5z!r|i8PGuVakN`z8^MZYp%
z3Cyxo$UP7(PUETHIv%L2?bt@V)Ysg1cBXx16GvmnIsXkO~G~H*`Tv%*0xP-F3OkV
zuy6J;Alc`T%^FzPzfx?DcpYu){B_`khtM#ba6e1P|A30kZOyZ3$^y?U~nBZeL
zzU@+Tb2+(uEcTP?M$=s4ZxxIQguJGk3T;b??W0?i8C6H0RWZ7-}btX}b)oAS!*
z`|`bP8a~GU`e+fze6P^_JWVc7HfJGK=6WxtHoZ)D@j?zNIN^V@4WB2zpxXVhUlX@
z%YNpo5S@9}Ibma|%GcUtZ{06$vrm5LoujPLR)VLov2u)3SZ|$r*R0)V9b@9EooN3V
zF7dnrS3G1wvmzi=ebEMXw@EjsiYC3s_BO5qzAvODqL?awiF+qj(%(-Q-`wTxit`)
zFp$FQG-~m)6tNwcC(kR7D-(JN+?vQD!_v%pAd7S=%VnN6CI)+KE8E=6#(o~@
z@garlkyq{B3ym97E}?~YWM(-qXT0TT+d)p?Y2x5pRDx0sgN3uQR82g?C8wg#GV
z-oLVKc1NW12-CuH`POT+E9@%oR`f~a+1A54XSTcyRgI9yV!DQvs*W{%^LmB4_i`O
z~TSB-|Oln8bH=~D=$7jRUPgr4Qs9$zYG1J4aNJAS((_c{_}t6Br%Q{^G#XZ^QV
z;P*_mKg9q?iG}0?sAFHpTq|cW}G3urWdN9z$p;{#6|SLGf4VzXg9`006Te?+NI4
z3@E4IcUq-E4!uTkyZIf3tw7=qPBPpqW^ZF)*2lgh)tg~=$C-mN0cyRig=0mK@
zs~lbKcBu*2LD0^dIJPJKJ#Ba_#V9m2gp47p1!;|UT2OwxZ%Pq*aae_5jo=3N@tYX
zk!kf=q7IXYYL==C+VaH_4;GBy(xkE+H_-eH?Y0l_Io9G^y9w?6c!}+`+lP(p8U`;
zOtf2Xcqw$%1py)iqVf@l-lqjUSZ`8*Uz44W-IzF^kByMQGNvWk#-Nyo{`f~9jPR%
zQ~aRcl;34t#6LALfO#0*%kQFv2)Y+#1K3OYhR%yREv1e-2icDH9|bP`;3bQo~9M
zRY_p(acQ`ZPUXnlsVBCye^0;Dnu??o2cB4Kc@lY7cH+!Kd|N`@*WSQ%M4N5_r^i{
ztbJv!wBO7qJKQK$zq6%LDu~b+Rl=DIeARGgUUtjycM@U!#wgX#h=$!6PD`ojnLMI;
zgYA|n6lSmG5%axF!)_G1N-3SZ1m5SZURFZp|ODKHYHAgFeiWUOY`_W;EwS-$tH

Re: [RFC] Don't display deleted tags after dive edit

[Dirk Hohndel]

On Thu, Oct 30, 2014 at 10:31:16PM +0300, Joseph W. Joshua wrote:
 The attached patch fixes issue #732 on trac. 
 
 Please check, I hope my approach is right.

Nope, doesn't seem to do it for me...

Of course trying to figure out WHY this didn't work made me dig in and so
I fixed it instead :-/

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

[PATCH] Set the number of O2 sensors for Poseidon MK6

[Miika Turkia]

Signed-off-by: Miika Turkia miika.tur...@gmail.com
---
 file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/file.c b/file.c
index 9861a03..42f8ef6 100644
--- a/file.c
+++ b/file.c
@@ -471,6 +471,7 @@ int parse_txt_file(const char *filename, const char *csv)
dive-dc.model = strdup(Poseidon MkVI Discovery);
dive-dc.deviceid = atoi(parse_mkvi_value(memtxt.buffer, Rig 
Serial number));
dive-dc.dctype = CCR;
+   dive-dc.no_o2sensors = 2;
 
dive-cylinder[cur_cylinder_index].type.size.mliter = 3000;
dive-cylinder[cur_cylinder_index].type.workingpressure.mbar = 
20;
-- 
1.9.1

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

Re: [RFC] Don't display deleted tags after dive edit

[Joseph W. Joshua]

 
 Nope, doesn't seem to do it for me...
 
 Of course trying to figure out WHY this didn't work made me dig in and so
 I fixed it instead :-/

Glad that its working

 
 /D

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

[PATCH] Fix inconsistent search result in HTML export

[Gehad Elrobey]

Patch is attached to fix some inconsistency in HTML exports search.
From 7da7578385511e516a6010e1186f3542ed0ca1d2 Mon Sep 17 00:00:00 2001
From: Gehad elrobey gehadelro...@gmail.com
Date: Fri, 31 Oct 2014 02:50:17 +0200
Subject: [PATCH] Fix inconsistent search result in HTML export

The advanced search drop down menu always showed the user selected
settings, even if this is a customized search (tag, location) that took
place by clicking on the search quick hyperlink.

This is fixed by saving the user default search preferences and changing
them temporarily when quick hyperlinks searching is used.

Fixes #723

Signed-off-by: Gehad elrobey gehadelro...@gmail.com
---
 theme/dive_export.html | 44 ++--
 theme/list_lib.js  |  2 ++
 2 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/theme/dive_export.html b/theme/dive_export.html
index 6f3708c..e171b07 100644
--- a/theme/dive_export.html
+++ b/theme/dive_export.html
@@ -139,8 +139,40 @@ window.onload=function(){
 	getDefaultColor();
 }
 
+var user_search_preference = {
+	location : true,
+	divemaster : true,
+	buddy : true,
+	notes : true,
+	tags : true
+};
+
+function set_search_dropdown(search_preference)
+{
+	console.log(search_preference);
+	searchingModules[location].enabled = search_preference.location;
+	document.getElementById(search_item_location).checked = search_preference.location;
+
+	searchingModules[divemaster].enabled = search_preference.divemaster;
+	document.getElementById(search_item_divemaster).checked = search_preference.divemaster;
+
+	searchingModules[buddy].enabled = search_preference.buddy;
+	document.getElementById(search_item_Buddy).checked = search_preference.buddy;
+
+	searchingModules[notes].enabled = search_preference.notes;
+	document.getElementById(search_item_Notes).checked = search_preference.notes;
+
+	searchingModules[tags].enabled = search_preference.tags;
+	document.getElementById(search_item_Tags).checked = search_preference.tags;
+}
+
 function changeAdvSearch(e){
-	searchingModules[e.value].enabled=e.checked;
+	// change user searching preference
+	user_search_preference[e.value] = e.checked;
+
+	//set search preference dropdown
+	set_search_dropdown(user_search_preference);
+
 	SearchModules(document.getElementById(search_input).value, null);
 }
 
@@ -158,11 +190,11 @@ function changeAdvSearch(e){
 		input id=search_input oninput=SearchModules(this.value, null) placeholder=search/
 		a id=adv_srch_sp onClick=showdiv() Advanced search/a
 		div id=advanced_search
-		input type=checkbox onchange=changeAdvSearch(this) value=location checkedLocationbr
-		input type=checkbox onchange=changeAdvSearch(this) value=divemaster checkedDivemasterbr
-		input type=checkbox onchange=changeAdvSearch(this) value=buddy checkedBuddybr
-		input type=checkbox onchange=changeAdvSearch(this) value=notes checkedNotesbr
-		input type=checkbox onchange=changeAdvSearch(this) value=tags checkedTagsbr
+		input type=checkbox onchange=changeAdvSearch(this) id=search_item_location value=location checkedLocationbr
+		input type=checkbox onchange=changeAdvSearch(this) id=search_item_divemaster value=divemaster checkedDivemasterbr
+		input type=checkbox onchange=changeAdvSearch(this) id=search_item_Buddy value=buddy checkedBuddybr
+		input type=checkbox onchange=changeAdvSearch(this) id=search_item_Notes value=notes checkedNotesbr
+		input type=checkbox onchange=changeAdvSearch(this) id=search_item_Tags value=tags checkedTagsbr
 		/div
 		div id=toolbox
 		select id=no_dives_selector onChange=setNumberOfDives(this)
diff --git a/theme/list_lib.js b/theme/list_lib.js
index b2dc13b..e50fc39 100644
--- a/theme/list_lib.js
+++ b/theme/list_lib.js
@@ -516,6 +516,7 @@ function Node(value)
 function Search_list_Modules(searchfor, searchOptions)
 {
 	document.getElementById(search_input).value = searchfor;
+	set_search_dropdown(searchOptions);
 	SearchModules(searchfor, searchOptions);
 }
 
@@ -531,6 +532,7 @@ function SearchModules(searchfor, searchOptions)
 		itemsToShow = olditemstoshow;
 		list_sort(sort_based_on);
 		viewInPage();
+		set_search_dropdown(user_search_preference);
 		return;
 	}
 
-- 
1.9.1

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