Re: iPhone crash

[Dirk Hohndel]

> On Jun 17, 2018, at 8:09 AM, Miika Turkia  wrote:
> 
> Here is a crash log of Subsurface-mobile related to cloud sync. Hopefully it 
> makes some sense to someone. Occurs when there is new data available on 
> cloud. After restart it seems that repo was successfully synced, even though 
> Subsurface-mobile crashed.

No symbols - that makes things a wee bit harder. I thought I had things set up 
so that crash dumps include symbols.
Need to look at the Xcode settings again. Crud.
Annoyingly, TestFlight claims that you have no crashes (but it also says that 
those data can be up to 72 hours delayed, so I need to go back there in a 
couple of days). Because in theory I should be able to import the crash info 
into Xcode which should then tell me where the crash happened, anyway.

Thanks

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

iPhone crash

[Miika Turkia]

Here is a crash log of Subsurface-mobile related to cloud sync. Hopefully it 
makes some sense to someone. Occurs when there is new data available on cloud. 
After restart it seems that repo was successfully synced, even though 
Subsurface-mobile crashed.

miika



Subsurface-mobile-2018-06-16-113236.ips.beta
Description: Binary data

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

Re: Robert, Stefan, Dive mode problems

[Robert Helling]

> On 16. Jun 2018, at 17:48, Stefan Fuchs  wrote:
> 
> Sorry for not joining the discussion for such a long time.

Sorry, this got lost in my inbox. I should be able to look into this very soon.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Robert, Stefan, Dive mode problems

[Stefan Fuchs]

Hello Willem, hallo Robert,


Am 01.06.2018 um 10:34 schrieb Willem Ferguson:
> Attached are the xml dive  header and dive computer description of a
> pSCR dive, as well as the UI rendering of the dive profile. Obviously
> there there are significant differences between the xml and the
> graphic derived from that dive log. The two most obvious discrepancies
> are:
>
> 1) In the UI, the dive computer is indicated as OC (see lefthand of
> screenshot). However, in the xml dive log it is indicated as PSCR.
>
> 2) The xml event at 10 min 14 sec into the dive is a divemode
> transition from OC to PSCR. However, on the dive profile it is
> indicated as transition from PSCR to OC.
>
> Now, the very real possibility exists that this results from
> Ferguson's own doings and code changes by him. However after all the
> bailout changes were performed the rendering of divemode changes
> worked perfectly. The latest changes pertain to the dive planner and
> code in planner.c, not affecting the dive log.
>
> The obvious suspect are the changes to the names of divemodes,
> separating the displayed names from the internal divemode names.
>
> Robert, Stefan, would it be possible to have a quick check to see if
> there is an obvious bug?
>
Sorry for not joining the discussion for such a long time.

I guess the issue described above was meanwhile fixed by Robert, wasn't it?

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

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

Re: new releases

[Robert C. Helling]

Hi,

> Am 16.06.2018 um 12:08 schrieb Miika Turkia :
> 
> was there some way to get the crash log out of iPhone? Running 4.7.8.287

Go to settings, privacy , analytics (or whatever that is called in your 
language). You’ll find everything there. 

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

Re: new releases

[Miika Turkia]

> On 16 Jun 2018, at 7.16, Dirk Hohndel  wrote:
> 
> What other bugs do we know of for either desktop or mobile?

I have had some crashes on iPhone when syncing new data from cloud. Apparently 
Subsurface-mobile crashes after the sync, as new data is available on next 
start.

was there some way to get the crash log out of iPhone? Running 4.7.8.287

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

Re: new releases

[Dirk Hohndel]

> On Jun 16, 2018, at 6:10 PM, Murillo Bernardes  wrote:
 
>>> mobile: the ssrf logo in the coral picture, still shows as a black spot.
>> 
>> Right. I noticed that as well.
>> 
> 
> This is a Kirigami bug. Unfortunately I could not track this the last
> two weeks. I'll get back to it now.

I'm fixing this right now...

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

Re: new releases

[Murillo Bernardes]

Murillo Bernardes

On Sat, Jun 16, 2018 at 7:41 AM Dirk Hohndel  wrote:
>
>
> > On Jun 16, 2018, at 2:01 PM, Jan Iversen  wrote:
> >>
> >> So far I found one odd bug in Subsurface-mobile with downloading from the 
> >> Suunto EON Steel. Even though I had new dives on the DC, Subsurface-mobile 
> >> told me there were no new dives. I added debug output and tried again, and 
> >> of course it worked correctly :-/
> > This also happens on the mobile version (master and test flight), with 
> > Suunto EON Core. I have seen it a couple of times. Connection with BLE is 
> > made correctly, firmware version etc. written on screen and then no dives 
> > found. If you try again without restarting ssrf it  works. I thought it was 
> > something like a ble tineout. There are no indications in the normal logs.
>
> Linus is looking into that one
>
> >> The other issue I see on Mac is that some of the dialogs have partially 
> >> cut off texts. I'm currently trying to figure out how to even debug this. 
> >> There's no reason I can figure out why those should not automatically size 
> >> correctly...
> > I can confirm that. It hits the divedetails window among others. I have not 
> > searched for it, but I saw about a month ago.
>
> I think I have fixed this. Waiting for comments from Robert
>
> >> What other bugs do we know of for either desktop or mobile?
> > mobile: the ssrf logo in the coral picture, still shows as a black spot.
>
> Right. I noticed that as well.
>

This is a Kirigami bug. Unfortunately I could not track this the last
two weeks. I'll get back to it now.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Berthold Stoeger]

Hi,

On Samstag, 16. Juni 2018 01:16:14 CEST Dirk Hohndel wrote:

> What other bugs do we know of for either desktop or mobile?

Not a bug, but perhaps remove the cryptic debug messages from 
libdivecomputer.c? I know I was confused. Proposed patch attached.

After the release, could we perhaps try to finally get PR#799 out (or 
trashed)? I have access to a Windows-PC, but I need feedback / suggestions.

Berthold
>From c1b89465957c2014ea5a2a593d1423e82dd82da0 Mon Sep 17 00:00:00 2001
From: Berthold Stoeger 
Date: Sat, 16 Jun 2018 10:50:30 +0200
Subject: [PATCH] libdc interface: remove debug messages

Don't spill supported transports as error message to the user.

Signed-off-by: Berthold Stoeger 
---
 core/libdivecomputer.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index 3443886b6..499428fc8 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -1212,19 +1212,6 @@ char *transport_string[] = {
 	"BLE"
 };
 
-static char *transport_to_string(int t)
-{
-	static char buf[1024];
-	buf[0] = '\0';
-	for (int i = 0; i < 6; i++) {
-		if (t & (1<___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto DM5 Imports broken

[Rainer Mohr]

Sent via personal mail to Miika

Rainer

Am 16.06.18 um 02:15 schrieb Miika Turkia:
I just sent a pull req that should take care of this. However, I do 
not possess test data with the new format. Could you Rainer send me a 
sample file? (The addition for support for the new format is quite 
trivial, but still I would like to test it out.)


miika

On Fri, Jun 15, 2018 at 12:32 AM, Miika Turkia > wrote:


I will try to take a look into this within a few days

miika

> On 8 Jun 2018, at 0.25, Dirk Hohndel mailto:d...@hohndel.org>> wrote:
>
> Miika is the wunderkind-slash-madman who maintains our importers
and deals with the XSLT...
>
> /D
>
>> On Jun 7, 2018, at 1:58 AM, Rainer Mohr mailto:m...@divelogs.de>> wrote:
>>
>> Gentlemen,
>>
>> Just noticed, that the Suunto DM5 Import is very broken as it
can't parse the profile data from recent and semi-recent DM5 files
properly.
>> Suunto has once again changed their data structures in the
profile part of DM5. Noticed after quite a few broken profiles
popped up on divelogs.de 
>> Now the 'SampleBlob' can contain not only blocks of 16, 23 and
26 Bytes, but new: 30 Bytes (detectable by first Byte being '5')
>>
>> Here is my PHP code for handling the profile parts from the
SQLite Data, hope someone can translate this into what you need,
as I would be useless at doing so:
>>
>> > // $databaserow contains the data from one dive, queried from
the database
>> $data = $databaserow['SampleBlob'];
>> $samples = Array();
>>
>> // Depending on first Byte: Samples are in blocks of 23 or 16
or 26 or 30 bytes
>> if (ord($data[0])==3) { // 23 Bytes per sample
>>    $data = substr($data,1,strlen($data));
>>    for($i = 0; $i < strlen($data)/23; ++$i) {
>>        $s =
unpack("f",$data[$i*23+2].$data[$i*23+3].$data[$i*23+4].$data[$i*23+5]);
>>        if ($s[1] < 200) $samples[] = round($s[1],1);
>>    }
>> } elseif (ord($data[0])==4) { // 26 Bytes per sample
>>    $data = substr($data,1,strlen($data));
>>    for($i = 0; $i < strlen($data)/26; ++$i) {
>>        $s =
unpack("f",$data[$i*26+2].$data[$i*26+3].$data[$i*26+4].$data[$i*26+5]);
>>        if ($s[1] < 200) $samples[] = round($s[1],1);
>>    }
>> } elseif (ord($data[0])==5) { // 30 Bytes per sample
>>    $data = substr($data,1,strlen($data));
>>    for($i = 0; $i < strlen($data)/30; ++$i) {
>>        $s =
unpack("f",$data[$i*30+2].$data[$i*30+3].$data[$i*30+4].$data[$i*30+5]);
>>        if ($s[1] < 200) $samples[] = round($s[1],1);
>>    }
>> } else { // 16 Bytes per sample
>>    for($i = 0; $i < strlen($data)/16; ++$i) {
>>        $s =
unpack("f",$data[$i*16+3].$data[$i*16+4].$data[$i*16+5].$data[$i*16+6]);
>>        if ($s[1] < 200) $samples[] = round($s[1],1);
>>    }
>> }
>>
>> // in case Dives from imported DM4 are available
>> if (count($samples)==0) {
>>    $data = $databaserow['ProfileBlob'];
>>    for($i = 0; $i < strlen($data)/4; ++$i) {
>>        $s =
unpack("f",$data[$i*4].$data[$i*4+1].$data[$i*4+2].$data[$i*4+3]);
>>        if ($s[1] < 200) $samples[] = round($s[1],1);
>>    }
>> }
>> ?>
>>
>> Rainer
>>
>>
>> ___
>> 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: new releases

[Linus Torvalds]

On Sat, Jun 16, 2018 at 4:26 PM Anton Lundin  wrote:
>
> Another approach to solve the FTDI issue in specific is to replace the
> serial_ftdi.c code all together with a implementation using the official
> android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
> with this is that we would drop support for all pure libusb devices,
> like the eon steel, and so on.

It's likely only the Atomic Aquatics Cobalt that we would need to worry about.

On a phone, you'd use BLE to talk to the EON Steel and the Scubapro
G2, which are the main usbhid users (which in turn uses libusb -
unless HIDPI works on Android?).

Of course, BLE is flaky, so USB *could* be good on Android, but let's
be honest - nobody is going to bother.

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

Re: new releases

[Anton Lundin]

On 16 June, 2018 - Dirk Hohndel wrote:

> 
> > On Jun 16, 2018, at 3:45 PM, Thomas Fänge  wrote:
> > 
> > HI all!
> > 
> > Dirk wrote:
> > 
> > >> What other bugs do we know of for either desktop or mobile?
> > 
> > What I would wish for, is that using a DC with OTG cable on the mobile 
> > version should work again. Apparently this worked before 4.7.5, and seems 
> > to be related to opening a FTDI port on Android (bug #1240).
> 
> I don't have a single Android device where our way of doing this ever worked 
> (and I have six different Android tablets and phones). So I can't help with 
> even testing this.
> What we really need is to fix libusb to be able to open the port.
> It seems that there are two approaches that people have been working on, if 
> anyone with an Android device and an FTDI dive computer wants to give it a 
> try:
> 
> This is the first one - that hasn't seen much activity in the last two years.
> 
> https://gitlab.com/madresistor/libusb/commits/android 
> 
> 
> This one seems more active, but again, someone would have to spend some 
> quality time on understanding how this would work from a Subsurface-mobile 
> perspective.
> 
> https://github.com/libusb/libusb/pull/242 
> 

I really don't like either of those two approaches. Both of them require
you to rewrite all the libusb-open code, which is going to be a pita for
us. We don't call libusb directly, we just call libdivecomputer or
libftdi which calls into libusb for us.


The approach I've worked on is to replace the discovery code in libusb
with something which jni's into android to provide the list of devices.
That way we still just modify libusb and let all the callers think
they're talking to a bog standard libusb on a normal system.

libusb is old egnough to have multiple backends for talking to different
generations of the usb interfaces so its resonably straight forward to
plumb in a "custom-android" backend which jni's into android filling in
the right data structures.

Somewhere I have some half ass first take at implementing this that
doesn't work.


Another approach to solve the FTDI issue in specific is to replace the
serial_ftdi.c code all together with a implementation using the official
android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
with this is that we would drop support for all pure libusb devices,
like the eon steel, and so on.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Thomas Fänge]

Ok, fair enough...

Vacation is coming up, and I could at least try to give it a go. I should
be able to debug etc, but first try to understand the code.

Cheers,
Thomas

Den lör 16 juni 2018 08:55Dirk Hohndel  skrev:

>
> On Jun 16, 2018, at 3:45 PM, Thomas Fänge  wrote:
>
> HI all!
>
> Dirk wrote:
>
> >> What other bugs do we know of for either desktop or mobile?
>
> What I would wish for, is that using a DC with OTG cable on the mobile
> version should work again. Apparently this worked before 4.7.5, and seems
> to be related to opening a FTDI port on Android (bug #1240).
>
>
> I don't have a single Android device where our way of doing this ever
> worked (and I have six different Android tablets and phones). So I can't
> help with even testing this.
> What we really need is to fix libusb to be able to open the port.
> It seems that there are two approaches that people have been working on,
> if anyone with an Android device and an FTDI dive computer wants to give it
> a try:
>
> This is the first one - that hasn't seen much activity in the last two
> years.
>
> https://gitlab.com/madresistor/libusb/commits/android
>
> This one seems more active, but again, someone would have to spend some
> quality time on understanding how this would work from a Subsurface-mobile
> perspective.
>
> https://github.com/libusb/libusb/pull/242
>
> /D
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Dirk Hohndel]

> On Jun 16, 2018, at 3:45 PM, Thomas Fänge  wrote:
> 
> HI all!
> 
> Dirk wrote:
> 
> >> What other bugs do we know of for either desktop or mobile?
> 
> What I would wish for, is that using a DC with OTG cable on the mobile 
> version should work again. Apparently this worked before 4.7.5, and seems to 
> be related to opening a FTDI port on Android (bug #1240).

I don't have a single Android device where our way of doing this ever worked 
(and I have six different Android tablets and phones). So I can't help with 
even testing this.
What we really need is to fix libusb to be able to open the port.
It seems that there are two approaches that people have been working on, if 
anyone with an Android device and an FTDI dive computer wants to give it a try:

This is the first one - that hasn't seen much activity in the last two years.

https://gitlab.com/madresistor/libusb/commits/android 


This one seems more active, but again, someone would have to spend some quality 
time on understanding how this would work from a Subsurface-mobile perspective.

https://github.com/libusb/libusb/pull/242 


/D


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

Re: new releases

[Thomas Fänge]

HI all!

Dirk wrote:

>> What other bugs do we know of for either desktop or mobile?

What I would wish for, is that using a DC with OTG cable on the mobile
version should work again. Apparently this worked before 4.7.5, and seems
to be related to opening a FTDI port on Android (bug #1240).

Best wishes,
Thomas


Den lör 16 juni 2018 08:15Linus Torvalds 
skrev:

> On Sat, Jun 16, 2018 at 2:40 PM Linus Torvalds
>  wrote:
> >
> > In the meantime, "just retry" is  the way to get it to work.
> > Eventually it will - at least as long as you're not trying to download
> > too much, and at least as long as the environment isn't too noisy for
> > BLE.
>
> I can also make the EON Core crash when there are enough BLE packet
> errors. It's probably because we do not re-try - we just fail that
> command and then go to the next one. Which will also usually fail,
> because we've now confused the EON Core.
>
> So I've gotten "SYSTEM FAILURE" "ERR - c150" three times today
> while trying to debug this. That resets the time and date on the dive
> computer, btw, but Suunto tells me that it doesn't affect the actual
> deco calculations even if it happens between dives.  I got similar
> things when I did things wrong over USB, so I'm not entirely
> surprised, but it  does make for more exciting debugging.
>
> I'll try to figure out what the proper re-try sequence is. I've
> already fixed some of my wrong assumptions of the protocol, but they
> don't really matter (the "connection ID" magic value isn't actually 4
> bytes, it's a 2-byte magic value and there are two bytes of flags.  I
> think that's where I need to fill in retransmit information is, but
> I'm flying mostly blind.
>
>  Linus
> ___
> 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: new releases

[Dirk Hohndel]

> On Jun 16, 2018, at 3:03 PM, Robert Helling  wrote:
> 
> Hi,
> 
>> On 16. Jun 2018, at 08:00, Robert Helling > > wrote:
>> 
>> I had a similar issue a few months ago with some progress dialogue. This was 
>> a Qt bug on Mac (which I filed) and did some work around for that specific 
>> dialogue. 
>> 
>> Let me try to find that. 
> 
> here it is:
> 
> https://github.com/Subsurface-divelog/subsurface/issues/1041 
> 
> https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list 
> 
> 
> Does this look familiar?

Yep. I wonder if my fix does the trick for you.

https://github.com/Subsurface-divelog/subsurface/pull/1383 

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

Re: new releases

[Linus Torvalds]

On Sat, Jun 16, 2018 at 2:40 PM Linus Torvalds
 wrote:
>
> In the meantime, "just retry" is  the way to get it to work.
> Eventually it will - at least as long as you're not trying to download
> too much, and at least as long as the environment isn't too noisy for
> BLE.

I can also make the EON Core crash when there are enough BLE packet
errors. It's probably because we do not re-try - we just fail that
command and then go to the next one. Which will also usually fail,
because we've now confused the EON Core.

So I've gotten "SYSTEM FAILURE" "ERR - c150" three times today
while trying to debug this. That resets the time and date on the dive
computer, btw, but Suunto tells me that it doesn't affect the actual
deco calculations even if it happens between dives.  I got similar
things when I did things wrong over USB, so I'm not entirely
surprised, but it  does make for more exciting debugging.

I'll try to figure out what the proper re-try sequence is. I've
already fixed some of my wrong assumptions of the protocol, but they
don't really matter (the "connection ID" magic value isn't actually 4
bytes, it's a 2-byte magic value and there are two bytes of flags.  I
think that's where I need to fill in retransmit information is, but
I'm flying mostly blind.

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

Re: new releases

[Jan Iversen]

> El 16 jun 2018, a las 8:03, Robert Helling  escribió:
> 
> Hi,
> 
>> On 16. Jun 2018, at 08:00, Robert Helling > > wrote:
>> 
>> I had a similar issue a few months ago with some progress dialogue. This was 
>> a Qt bug on Mac (which I filed) and did some work around for that specific 
>> dialogue. 
>> 
>> Let me try to find that. 
> 
> here it is:
> 
> https://github.com/Subsurface-divelog/subsurface/issues/1041 
> 
> https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list 
> 
> 
> Does this look familiar?
That is exactly what I have on my Mac :-(
(Qt 5.10)

rgds
Jan I
> 
> Robert
> ___
> 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: new releases

[Robert Helling]

Hi,

> On 16. Jun 2018, at 08:00, Robert Helling  wrote:
> 
> I had a similar issue a few months ago with some progress dialogue. This was 
> a Qt bug on Mac (which I filed) and did some work around for that specific 
> dialogue.
> 
> Let me try to find that.

here it is:

https://github.com/Subsurface-divelog/subsurface/issues/1041 

https://bugreports.qt.io/browse/QTBUG-65750?attachmentViewMode=list 


Does this look familiar?

Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: new releases

[Robert Helling]

Dirk,

> On 16. Jun 2018, at 07:41, Dirk Hohndel  wrote:
> 
>>> The other issue I see on Mac is that some of the dialogs have partially cut 
>>> off texts. I'm currently trying to figure out how to even debug this. 
>>> There's no reason I can figure out why those should not automatically size 
>>> correctly...
>> I can confirm that. It hits the divedetails window among others. I have not 
>> searched for it, but I saw about a month ago.
> 
> I think I have fixed this. Waiting for comments from Robert

I had a similar issue a few months ago with some progress dialogue. This was a 
Qt bug on Mac (which I filed) and did some work around for that specific 
dialogue.

Let me try to find that.

For which windows did you encounter this?

Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface