Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 06:19, Lubomir I. Ivanov  wrote:
>
> On Sat, 29 Sep 2018 at 06:10, Dirk Hohndel  wrote:
> >
> >
> > > On Sep 28, 2018, at 8:07 PM, Lubomir I. Ivanov  
> > > wrote:
> > >
> > > according to a post here UWP apps are only accessible via the Windows 
> > > Store:
> > > https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html
> > >
> > > if it's not installed via the Windows Store this means the Shearwater
> > > devs know something that we don't know, as the Qt developers assured
> > > me non-UWP apps don't have access to the pair API.
> >
> > Nope, not from the store. And DEFINITELY the app can pair with their
> > dive computers without a problem. It finds the quickly and very reliably.
> >
>
> i can investigate their binary a little.
> we also have the option to just ask them - are they friendly?
>

on a quick look Sheerwater Cloud is written in C#, saw some dot-net
EXE patchers and also the Mono runtime in their installer.

so we are probably dealing with a case where it's not about UWP, but
rather C# vs C:

also the Microsoft pairing examples are in C#:
https://github.com/Microsoft/Windows-universal-samples/blob/master/Samples/BluetoothLE/cs/Scenario1_Discovery.xaml.cs#L306
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/BluetoothLE/cs

for Subsurface, we don't have an option other than the one we have ATM.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 06:10, Dirk Hohndel  wrote:
>
>
> > On Sep 28, 2018, at 8:07 PM, Lubomir I. Ivanov  wrote:
> >
> > according to a post here UWP apps are only accessible via the Windows Store:
> > https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html
> >
> > if it's not installed via the Windows Store this means the Shearwater
> > devs know something that we don't know, as the Qt developers assured
> > me non-UWP apps don't have access to the pair API.
>
> Nope, not from the store. And DEFINITELY the app can pair with their
> dive computers without a problem. It finds the quickly and very reliably.
>

i can investigate their binary a little.
we also have the option to just ask them - are they friendly?

> I'll bring you the Perdix AI next week, then you can try this first hand.

sounds good.

> >>>
>
> >>> - does the list of devices gets populated even if the red Subsurface
> >>> error is shown?
> >>
> >> Sometimes it gets populated with BT devices if I select Auto instead
> >> of Force LE. But if I get the error I mentioned, then it isn't populated
> >>
> >
> > if it's only happening sometimes, it could be do two a couple of reasons:
> > - malfunctioning chip on the laptop.
> > - a software hook interrupting the scan. AV software can do that.
>
> But why doesn't that happen to Shearwater Cloud???
>

i did a good amount of investigation on this and also asked around.

it might be a case where it's not about UWP vs non-UWP but rather (C#
or C++) vs C.
for instance this post confirms my findings. [1]


i need to go to bed now, will investigate more tomorrow or on Sunday.
in the meantime if you can try another Windows machine and if we can
get more feedback from users it would be great!

[1]
https://stackoverflow.com/questions/19959261/how-to-scan-for-bluetooth-low-energy-devices-in-windows-8-desktop

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 8:07 PM, Lubomir I. Ivanov  wrote:
> 
> according to a post here UWP apps are only accessible via the Windows Store:
> https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html
> 
> if it's not installed via the Windows Store this means the Shearwater
> devs know something that we don't know, as the Qt developers assured
> me non-UWP apps don't have access to the pair API.

Nope, not from the store. And DEFINITELY the app can pair with their
dive computers without a problem. It finds the quickly and very reliably.

I'll bring you the Perdix AI next week, then you can try this first hand.
>>> 

>>> - does the list of devices gets populated even if the red Subsurface
>>> error is shown?
>> 
>> Sometimes it gets populated with BT devices if I select Auto instead
>> of Force LE. But if I get the error I mentioned, then it isn't populated
>> 
> 
> if it's only happening sometimes, it could be do two a couple of reasons:
> - malfunctioning chip on the laptop.
> - a software hook interrupting the scan. AV software can do that.

But why doesn't that happen to Shearwater Cloud???

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 06:07, Lubomir I. Ivanov  wrote:
> >
> > Sometimes it gets populated with BT devices if I select Auto instead
> > of Force LE. But if I get the error I mentioned, then it isn't populated
> >
>
> if it's only happening sometimes, it could be do two a couple of reasons:

*it could be due to...

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 06:01, Dirk Hohndel  wrote:
>
>
> > On Sep 28, 2018, at 7:58 PM, Lubomir I. Ivanov  wrote:
> >
> > - is Shearwater Cloud an Universal Windows Platform app, those support
> > scanning and pairing, unlike Subsurface which is a native app?
>
> How can I tell? (sorry)

according to a post here UWP apps are only accessible via the Windows Store:
https://www.tenforums.com/software-apps/47840-how-do-i-know-if-installed-app-universal-app.html

if it's not installed via the Windows Store this means the Shearwater
devs know something that we don't know, as the Qt developers assured
me non-UWP apps don't have access to the pair API.

>
> > - i wonder if anti-virus is at play here, do you have an option to
> > temp disable it?
>
> Work laptop. Let's try :-)

might require admin privileges.

>
> > - did you try deleting all DCs from control panel -> restarting ->
> > adding them again?
>
> I will do that next

ok.

>
> > - does the list of devices gets populated even if the red Subsurface
> > error is shown?
>
> Sometimes it gets populated with BT devices if I select Auto instead
> of Force LE. But if I get the error I mentioned, then it isn't populated
>

if it's only happening sometimes, it could be do two a couple of reasons:
- malfunctioning chip on the laptop.
- a software hook interrupting the scan. AV software can do that.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

Funny thing just happened. I did Force LE and another scan. And it found two 
devices.
Bose LE speakers and one of my Nest smoke detectors. Neither of which is paired 
with
my laptop.

What it didn't find was any of the three BLE dive computers :-/

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 7:58 PM, Lubomir I. Ivanov  wrote:
> 
> - is Shearwater Cloud an Universal Windows Platform app, those support
> scanning and pairing, unlike Subsurface which is a native app?

How can I tell? (sorry)

> - i wonder if anti-virus is at play here, do you have an option to
> temp disable it?

Work laptop. Let's try :-)

> - did you try deleting all DCs from control panel -> restarting ->
> adding them again?

I will do that next

> - does the list of devices gets populated even if the red Subsurface
> error is shown?

Sometimes it gets populated with BT devices if I select Auto instead
of Force LE. But if I get the error I mentioned, then it isn't populated

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 05:52, Dirk Hohndel  wrote:
>
>
> > On Sep 28, 2018, at 7:46 PM, Dirk Hohndel  wrote:
> >
> >>
> >> On Sep 28, 2018, at 7:43 PM, Lubomir I. Ivanov  wrote:
> >>
> >> On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel  wrote:
> >>>
> >>>
>  On Sep 28, 2018, at 7:26 PM, Dirk Hohndel  wrote:
> 
>  Given the nature of the error message I'm thinking this might be an
>  unhealthy mix of versions...
> >>>
> >>> To test this theory I dug out a Bluetooth dive computer (an original 
> >>> BT-only
> >>> Shearwater Petrel) and had no problem connecting to it and downloading
> >>> dives from it.
> >>>
> >>> So now I'm no longer sure where the problem might be...
> >>>
> >>
> >> i'm not sure either, but it seems that the OSTC+ works for me using that 
> >> build.
> >>
> >> so i guess on your side we have an issue that other users might face as 
> >> well.
> >> the device discovery and pairing is problematic on Windows...and i've
> >> raised that concern before.
> >>
> >> i wonder if a restart + removing + adding / pairing the devices would help.
> >> on my side a restart often helps in cases the device cannot be found.
> >
> > So Windows tells me it sees the devices and is paired with both of them.
> > I tried removing one or the other. Of course they are both very similar.
> > I'll try another BLE dive computer that I have and see if that will play
> > along...
>
> I installed Shearwater Cloud on that machine. It immediately connects
> with both computers. Even while it is scanning, a scan with Subsurface
> fails
>

- is Shearwater Cloud an Universal Windows Platform app, those support
scanning and pairing, unlike Subsurface which is a native app?
- i wonder if anti-virus is at play here, do you have an option to
temp disable it?
- did you try deleting all DCs from control panel -> restarting ->
adding them again?
- does the list of devices gets populated even if the red Subsurface
error is shown?

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 7:46 PM, Dirk Hohndel  wrote:
> 
>> 
>> On Sep 28, 2018, at 7:43 PM, Lubomir I. Ivanov  wrote:
>> 
>> On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel  wrote:
>>> 
>>> 
 On Sep 28, 2018, at 7:26 PM, Dirk Hohndel  wrote:
 
 Given the nature of the error message I'm thinking this might be an
 unhealthy mix of versions...
>>> 
>>> To test this theory I dug out a Bluetooth dive computer (an original BT-only
>>> Shearwater Petrel) and had no problem connecting to it and downloading
>>> dives from it.
>>> 
>>> So now I'm no longer sure where the problem might be...
>>> 
>> 
>> i'm not sure either, but it seems that the OSTC+ works for me using that 
>> build.
>> 
>> so i guess on your side we have an issue that other users might face as well.
>> the device discovery and pairing is problematic on Windows...and i've
>> raised that concern before.
>> 
>> i wonder if a restart + removing + adding / pairing the devices would help.
>> on my side a restart often helps in cases the device cannot be found.
> 
> So Windows tells me it sees the devices and is paired with both of them.
> I tried removing one or the other. Of course they are both very similar.
> I'll try another BLE dive computer that I have and see if that will play
> along...

I installed Shearwater Cloud on that machine. It immediately connects
with both computers. Even while it is scanning, a scan with Subsurface
fails

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 7:43 PM, Lubomir I. Ivanov  wrote:
> 
> On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel  wrote:
>> 
>> 
>>> On Sep 28, 2018, at 7:26 PM, Dirk Hohndel  wrote:
>>> 
>>> Given the nature of the error message I'm thinking this might be an
>>> unhealthy mix of versions...
>> 
>> To test this theory I dug out a Bluetooth dive computer (an original BT-only
>> Shearwater Petrel) and had no problem connecting to it and downloading
>> dives from it.
>> 
>> So now I'm no longer sure where the problem might be...
>> 
> 
> i'm not sure either, but it seems that the OSTC+ works for me using that 
> build.
> 
> so i guess on your side we have an issue that other users might face as well.
> the device discovery and pairing is problematic on Windows...and i've
> raised that concern before.
> 
> i wonder if a restart + removing + adding / pairing the devices would help.
> on my side a restart often helps in cases the device cannot be found.

So Windows tells me it sees the devices and is paired with both of them.
I tried removing one or the other. Of course they are both very similar.
I'll try another BLE dive computer that I have and see if that will play
along...

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 05:33, Dirk Hohndel  wrote:
>
>
> > On Sep 28, 2018, at 7:26 PM, Dirk Hohndel  wrote:
> >
> > Given the nature of the error message I'm thinking this might be an
> > unhealthy mix of versions...
>
> To test this theory I dug out a Bluetooth dive computer (an original BT-only
> Shearwater Petrel) and had no problem connecting to it and downloading
> dives from it.
>
> So now I'm no longer sure where the problem might be...
>

i'm not sure either, but it seems that the OSTC+ works for me using that build.

so i guess on your side we have an issue that other users might face as well.
the device discovery and pairing is problematic on Windows...and i've
raised that concern before.

i wonder if a restart + removing + adding / pairing the devices would help.
on my side a restart often helps in cases the device cannot be found.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 7:26 PM, Dirk Hohndel  wrote:
> 
> Given the nature of the error message I'm thinking this might be an
> unhealthy mix of versions...

To test this theory I dug out a Bluetooth dive computer (an original BT-only
Shearwater Petrel) and had no problem connecting to it and downloading
dives from it.

So now I'm no longer sure where the problem might be...

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

Given the nature of the error message I'm thinking this might be an
unhealthy mix of versions... so I'm creating a fresh Qt 5.11.2 on the
server - this one won't have QtWebKit, though.

And then I'll install your QtConnectivity over what's in there.

And create a new build with that.

But even on a relatively fast server, recompiling all of Qt does take 
a while. So given that it's rather early for you (even by your own insane
standard), I'd suggest you get some rest, Lubomir

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:59 PM, Lubomir I. Ivanov  wrote:
> 
> On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel  wrote:
>> 
>> 
>>> On Sep 28, 2018, at 6:53 PM, Dirk Hohndel  wrote:
>>> 
>>> 
 On Sep 28, 2018, at 6:51 PM, Dirk Hohndel  wrote:
 
 No. In the Subsurface divecomputer download dialog I click on the '...' 
 behind the
 Bluetooth mode text to open the scan window. There I click scan and some 
 times
 it will show me some (actually, only a few) of the many many BT/BLE 
 devices in
 my office, but about half of the time it will tell me that there was an 
 error scanning
 because the BT device is off.
 
>>> 
>>> The exact text is (below the Clear button)
>>> 
>>> Device discovery error: The Bluetooth adaptor is powered off, power it on 
>>> before
>>> doing discovery
>> 
>> And of course the adapter is in fact on and in the Windows settings I see 
>> both of
>> the BLE dive computers that I have sitting next to me right now...
>> 
> 
> i can reproduce this error if i go into the control plane and turn
> bluetooth off manually.

I just realized that this is our error that we print out if we get to

void 
BtDeviceSelectionDialog::deviceDiscoveryError(QBluetoothDeviceDiscoveryAgent::Error
 error)
{
QString errorDescription;

switch (error) {
case QBluetoothDeviceDiscoveryAgent::PoweredOffError:
errorDescription = tr("The Bluetooth adaptor is powered off, 
power it on before doing discovery.");
break;

So this sounds to me like I'm getting an error I shouldn't be getting. The 
question is of 
course if this is a result of running the MXE Qt 5.10.1 binaries with the one 
library built
from your sources...

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 04:59, Lubomir I. Ivanov  wrote:
>
> On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel  wrote:
> >
> > If you want to play with my binary, there are currently two on 
> > downloads/test
> >
> > The -90 is the test binary for 4.8.3 with unmodified Bluetooth libraries
> > The -91 is the one with your branch of QtBluetooth
> >
>
> ok, trying.
>

i cannot install Subsurface from the installer on the IT laptop
(screenshot attached).
looking for ways, but it seems blocked by WindowsDefender and there is
no privileges for me to unblock that.

if you can ZIP + upload the contents for me - i can test.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 04:59, Lubomir I. Ivanov  wrote:
>
> On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel  wrote:
> >
> >
> > > On Sep 28, 2018, at 6:53 PM, Dirk Hohndel  wrote:
> > >
> > >
> > >> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel  wrote:
> > >>
> > >> No. In the Subsurface divecomputer download dialog I click on the '...' 
> > >> behind the
> > >> Bluetooth mode text to open the scan window. There I click scan and some 
> > >> times
> > >> it will show me some (actually, only a few) of the many many BT/BLE 
> > >> devices in
> > >> my office, but about half of the time it will tell me that there was an 
> > >> error scanning
> > >> because the BT device is off.
> > >>
> > >
> > > The exact text is (below the Clear button)
> > >
> > > Device discovery error: The Bluetooth adaptor is powered off, power it on 
> > > before
> > > doing discovery
> >
> > And of course the adapter is in fact on and in the Windows settings I see 
> > both of
> > the BLE dive computers that I have sitting next to me right now...
> >
>
> i can reproduce this error if i go into the control plane

*panel.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Sat, 29 Sep 2018 at 04:57, Dirk Hohndel  wrote:
>
>
> > On Sep 28, 2018, at 6:53 PM, Dirk Hohndel  wrote:
> >
> >
> >> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel  wrote:
> >>
> >> No. In the Subsurface divecomputer download dialog I click on the '...' 
> >> behind the
> >> Bluetooth mode text to open the scan window. There I click scan and some 
> >> times
> >> it will show me some (actually, only a few) of the many many BT/BLE 
> >> devices in
> >> my office, but about half of the time it will tell me that there was an 
> >> error scanning
> >> because the BT device is off.
> >>
> >
> > The exact text is (below the Clear button)
> >
> > Device discovery error: The Bluetooth adaptor is powered off, power it on 
> > before
> > doing discovery
>
> And of course the adapter is in fact on and in the Windows settings I see 
> both of
> the BLE dive computers that I have sitting next to me right now...
>

i can reproduce this error if i go into the control plane and turn
bluetooth off manually.

>
> If you want to play with my binary, there are currently two on downloads/test
>
> The -90 is the test binary for 4.8.3 with unmodified Bluetooth libraries
> The -91 is the one with your branch of QtBluetooth
>

ok, trying.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:53 PM, Dirk Hohndel  wrote:
> 
> 
>> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel  wrote:
>> 
>> No. In the Subsurface divecomputer download dialog I click on the '...' 
>> behind the
>> Bluetooth mode text to open the scan window. There I click scan and some 
>> times
>> it will show me some (actually, only a few) of the many many BT/BLE devices 
>> in
>> my office, but about half of the time it will tell me that there was an 
>> error scanning
>> because the BT device is off.
>> 
> 
> The exact text is (below the Clear button)
> 
> Device discovery error: The Bluetooth adaptor is powered off, power it on 
> before
> doing discovery

And of course the adapter is in fact on and in the Windows settings I see both 
of
the BLE dive computers that I have sitting next to me right now...


If you want to play with my binary, there are currently two on downloads/test

The -90 is the test binary for 4.8.3 with unmodified Bluetooth libraries
The -91 is the one with your branch of QtBluetooth

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:51 PM, Dirk Hohndel  wrote:
> 
> No. In the Subsurface divecomputer download dialog I click on the '...' 
> behind the
> Bluetooth mode text to open the scan window. There I click scan and some times
> it will show me some (actually, only a few) of the many many BT/BLE devices in
> my office, but about half of the time it will tell me that there was an error 
> scanning
> because the BT device is off.
> 

The exact text is (below the Clear button)

Device discovery error: The Bluetooth adaptor is powered off, power it on before
doing discovery

/D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:44 PM, Lubomir I. Ivanov  wrote:
> 
> On 29 September 2018 at 04:42, Dirk Hohndel  wrote:
>> One thing that I noticed with only BTSUPPORT was that every other time that
>> I tried to scan for Bluetooth devices in Subsurface, it would tell me that 
>> the
>> Bluetooth adapter was turned off. Have you seen that behavior?
>> 
> 
> no, i haven't.
> is that one of the red messages we show at the bottom of the main window?

No. In the Subsurface divecomputer download dialog I click on the '...' behind 
the
Bluetooth mode text to open the scan window. There I click scan and some times
it will show me some (actually, only a few) of the many many BT/BLE devices in
my office, but about half of the time it will tell me that there was an error 
scanning
because the BT device is off.

Sending a screenshot would be rather painful - is this description sufficient?

(of course the fact that that POS is at 100% CPU with the McAfee Threat 
Protection
nonsense might not help...)

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 04:42, Dirk Hohndel  wrote:
> One thing that I noticed with only BTSUPPORT was that every other time that
> I tried to scan for Bluetooth devices in Subsurface, it would tell me that the
> Bluetooth adapter was turned off. Have you seen that behavior?
>

no, i haven't.
is that one of the red messages we show at the bottom of the main window?

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

One thing that I noticed with only BTSUPPORT was that every other time that
I tried to scan for Bluetooth devices in Subsurface, it would tell me that the
Bluetooth adapter was turned off. Have you seen that behavior?

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 04:13, Dirk Hohndel  wrote:
>
>> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov  wrote:
>>> Nope, much easier. Case sensitive file system. Simply changing it to 
>>> winsock2.h does the trick.
>>>
>>
>> looks like a potential patch i can send.
>
> yep. make it all lowercase :-)

patch sent:
https://codereview.qt-project.org/#/c/241465/

>
>> yes, that header should be in the same location where windows.h is.
>
> Indeed, and with that I have a successful build.
> Now I'm trying to put the files in place and create a new Subsurface build
>

good to hear,
at this point the QtBluettooth* DLLs are required as part of the deployment.

and for Subsurface's CMake: -DBLESUPPORT=1 -DBTSUPPORT=1

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov  wrote:
>> Nope, much easier. Case sensitive file system. Simply changing it to 
>> winsock2.h does the trick.
>> 
> 
> looks like a potential patch i can send.

yep. make it all lowercase :-)

> yes, that header should be in the same location where windows.h is.

Indeed, and with that I have a successful build.
Now I'm trying to put the files in place and create a new Subsurface build

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 04:04, Dirk Hohndel  wrote:
>
>> On Sep 28, 2018, at 6:01 PM, Dirk Hohndel  wrote:
>> I use i686-w64-mingw32.shared-gcc (GCC) 4.9.4 as that's what's part of MXE 
>> right now.
>> I wonder why there isn't a gcc5
>
> there apparently is, but I haven't installed it. Looking into that.
>
>> A little while into the build I get this error:
>>
>> qbluetoothservicediscoveryagent_win.cpp:50:22: fatal error: WinSock2.h: No 
>> such file or directory
>>
>> I appear to be missing some part of the dev environment. Let's see what 
>> Google tells me about that with MXE :-)
>
> Nope, much easier. Case sensitive file system. Simply changing it to 
> winsock2.h does the trick.
>

looks like a potential patch i can send.
yes, that header should be in the same location where windows.h is.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:01 PM, Dirk Hohndel  wrote:
> I use i686-w64-mingw32.shared-gcc (GCC) 4.9.4 as that's what's part of MXE 
> right now.
> I wonder why there isn't a gcc5

there apparently is, but I haven't installed it. Looking into that.

> A little while into the build I get this error:
> 
> qbluetoothservicediscoveryagent_win.cpp:50:22: fatal error: WinSock2.h: No 
> such file or directory
> 
> I appear to be missing some part of the dev environment. Let's see what 
> Google tells me about that with MXE :-)

Nope, much easier. Case sensitive file system. Simply changing it to winsock2.h 
does the trick.

/D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 5:56 PM, Lubomir I. Ivanov  wrote:
> 
> after accepting the license i see:
> 
> ---
> ...
> 
> Qt Bluetooth:
>  BlueZ .. no
>  BlueZ Low Energy ... no
>  Linux Crypto API ... no
>  WinRT Bluetooth API (desktop & UWP)  no
> 
> 

How odd looking

> at this point i run the above CMD file to build QtConnectivity.
> 
> my GCC is:
> gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

I use i686-w64-mingw32.shared-gcc (GCC) 4.9.4 as that's what's part of MXE 
right now.
I wonder why there isn't a gcc5

A little while into the build I get this error:

qbluetoothservicediscoveryagent_win.cpp:50:22: fatal error: WinSock2.h: No such 
file or directory

I appear to be missing some part of the dev environment. Let's see what Google 
tells me about that with MXE :-)

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 03:10, Dirk Hohndel  wrote:
> On Fri, Sep 28, 2018 at 11:10:48PM +0300, Lubomir I. Ivanov wrote:
>>
>> once the Qt tree is in place this branch has to be fetched:
>> http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win
>>
>> cd qtconnectivity
>> git fetch origin wip/win:wip/win
>> git checkout wip/win
>
> that part is easy.
>
>> at this point building Qt should use that branch.
>>
>> please mind that i every time i try to rebuild Qt something breaks for
>> me, so i'm probably not the best person on giving advise how to build
>> Qt.
>>
>> here is my windows CMD script for rebuilding + installing only 
>> qtconnectivity:
>> 
>> @echo off
>> cls
>> echo 
>> echo CLEANUP...
>> del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth*
>> echo BUILDING...
>> make -j4 module-qtconnectivity > NUL
>> :: make -j4 module-qtdeclarative > NUL
>
> This assumes you already have a makefile. Here's what I got so far:
>
> /data/win/mxe-master/usr/bin/i686-w64-mingw32.shared-qmake-qt5
> Info: creating stash file 
> /data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.stash
> Info: creating cache file 
> /data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.cache
>
> Running configuration tests...
> Checking for BlueZ... no
> Checking for WinRT Bluetooth API... no
> Done running configuration tests.
>
> Configure summary:
>
> Qt Bluetooth:
>   BlueZ .. no
>   BlueZ Low Energy ... no
>   Linux Crypto API ... no
>   WinRT Bluetooth API (desktop & UWP)  no
>
> That looks odd. Looks like I have no BT support at all. Is that what you
> see as well?


yes,

my config command line is:
configure -developer-build -opensource -nomake examples -nomake tests
-no-opengl -no-qml-debug -skip qtwebengine

after accepting the license i see:

---
...

Qt Bluetooth:
  BlueZ .. no
  BlueZ Low Energy ... no
  Linux Crypto API ... no
  WinRT Bluetooth API (desktop & UWP)  no


at this point i run the above CMD file to build QtConnectivity.

my GCC is:
gcc version 5.3.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

On Fri, Sep 28, 2018 at 11:10:48PM +0300, Lubomir I. Ivanov wrote:
> 
> once the Qt tree is in place this branch has to be fetched:
> http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win
> 
> cd qtconnectivity
> git fetch origin wip/win:wip/win
> git checkout wip/win

that part is easy.

> at this point building Qt should use that branch.
> 
> please mind that i every time i try to rebuild Qt something breaks for
> me, so i'm probably not the best person on giving advise how to build
> Qt.
> 
> here is my windows CMD script for rebuilding + installing only qtconnectivity:
> 
> @echo off
> cls
> echo 
> echo CLEANUP...
> del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth*
> echo BUILDING...
> make -j4 module-qtconnectivity > NUL
> :: make -j4 module-qtdeclarative > NUL

This assumes you already have a makefile. Here's what I got so far:

/data/win/mxe-master/usr/bin/i686-w64-mingw32.shared-qmake-qt5
Info: creating stash file 
/data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.stash
Info: creating cache file 
/data/winqt571/mxe-master/dirkhh/qtconnectivity/.qmake.cache

Running configuration tests...
Checking for BlueZ... no
Checking for WinRT Bluetooth API... no
Done running configuration tests.

Configure summary:

Qt Bluetooth:
  BlueZ .. no
  BlueZ Low Energy ... no
  Linux Crypto API ... no
  WinRT Bluetooth API (desktop & UWP)  no

That looks odd. Looks like I have no BT support at all. Is that what you
see as well?

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 4:47 PM, Lubomir I. Ivanov  wrote:
> recorded a quick video tutorial about pairing BLE devices on Windows 10:
> https://www.dropbox.com/s/1jivnitub9vq6do/win32_ble_tutorial.mp4?dl=0

This is awesome! Once we have official test binaries that support BLE on 
Windows we definitely should include this video!

/D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On Thu, 27 Sep 2018 at 01:04, Lubomir I. Ivanov  wrote:
>
> looks like the recent libdc + BLE refactor in Subsurface fixed the
> issues i was having downloading from the OSTC+ on Windows, with my
> custom Qt build.
> so it wasn't an issue in the Qt stack.
>
> thanks goes to Linus, because i was stuck on this not being able to
> figure out what's going on for a long time...
>
> log for proof:
> https://pastebin.com/7DHZU855
>
> --
>
> link for testing my latest Subsurface test build for BLE on Win32:
> https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0
>
> instructions:
>
> prerequisites:
> - minimum Windows version for this is 8.1
> - make sure that Windows has detected and paired with your DC
>
> steps:
> - extract the _deploy_win32_ble.zip ZIP in a folder somewhere
> - navigate to the folder with Explorer and start _run.cmd
> - a console window should open and next to it the Subsurface window
> - start your BLE dive-computer and make it ready for downloading of dives
> - in Subsurface goto Import -> Download from divecomputer
> - select the following options (and pick paths):
>  [x] Save libdivecomputer dumpfile
>  [x] Save libdivecomputer logfile
> - select the following option:
>  [x] Choose bluetooth download mode
> - a dialog should open. select "Force LE" for mode, and click "Scan".
> - your device should appear in the list. select it and click "Save"
> - the "Device or mount point" field should now show your DC.
> - click "Download".
>
> report back logs and dump files if it doesn't work for you.
>

recorded a quick video tutorial about pairing BLE devices on Windows 10:
https://www.dropbox.com/s/1jivnitub9vq6do/win32_ble_tutorial.mp4?dl=0

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

Translations and test binaries [was: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?]

[Dirk Hohndel]

Here’s where we are:

Test binaries are app for all platforms: 
Windows: 
http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-90-ge0e20edd87af.exe
Mac: 
http://subsurface-divelog.org/downloads/test/Subsurface-4.8.2-90-ge0e20edd87af.dmg
AppImage: 
https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/Subsurface-4.8.2-90-ge0e20edd87af-x86_64.AppImage
Ubuntu is on Launchpad
OpenSUSE is on OBS
Fedora builds failed again on OBS, need to look into what I messed up this time 
- it looks like my fix for the appdata.xml didn’t actually work
Android: 
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.2.90-arm.apk 
- but also pushed to Google Play beta channel
iOS has been submitted for review, should show up “soon”

It would be great to make sure we have at least some testing for these binaries 
- reports “hey, did a quick test, nothing seems broken” (or the opposite :-( ) 
would be extremely helpful so that we at least have some indication how much 
testing this has gotten.

Many translations have already been completed - you people are AMAZING!!!

If all goes well I’ll create this “quick release” on Saturday :-)

Thanks

/D



> On Sep 28, 2018, at 2:54 PM, Dirk Hohndel  wrote:
> 
>> 
>> On Sep 28, 2018, at 1:11 PM, Jan Mulder  wrote:
>> 
>> On 9/28/18 6:44 PM, Dirk Hohndel wrote:
 On Sep 28, 2018, at 8:36 AM, Jan Mulder  wrote:
 
 On 9/28/18 5:24 PM, Dirk Hohndel wrote:
> A rather embarrassing bug in my Shearwater Teric code, Linus' awesome 
> work on Mares BlueLink Pro support,
> The improvements to the mobile UI. The dive computer shortcut buttons.
> Yes, it's a bit of a rush job. But I'm wondering if we could do this.
> Thoughts?
 
 With respect to the mobile UI: ACK for a 2.1.4
 
 Just push the strings to Transifex to get things translated.
>>> Done
>> 
>> Ok, NL translation is also done.
>> 
>> BUT: my optimistic view on the mobile UI was wrong. Just found a (massive) 
>> bug in the new Kirigami. Just verified this by reverting commit 
>> 17ec95e70c3ae58 (to get back to the previous SHA).
>> 
>> So needed: revert both 17ec95e70c3ae58 and 40766db459b21.
>> 
>> Bug is related to the page stack and swiping through dives and returning to 
>> the list by the breadcrumb (instead of the menu). Sometimes this results in 
>> a page that shows both the divelist and the divedetail page on top of each 
>> other. Easy to get to a sane state again from that (just select the dive 
>> list from the menu), so not a real showstopper, but it look ugly.
> 
> UGH.
> 
> Ok, reverting those two. I got side-tracked with work and real life but I’m 
> hoping to have reviewed what we have committed since 4.8.2 / 2.1.3 so I can 
> have reasonable test build for everyone to play with tonight.
> 
> /D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 3:48 PM, Lubomir I. Ivanov  wrote:
> i think it's best, instead of trusting my memory, to just try building
> the QtConnectivity module from the wip/win branch against the version
> of Qt that you currently have (Qt 5.10.1) and see how it goes.
> please share error logs, if any.

Will do later this afternoon.

/D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 3:18 PM, Lubomir I. Ivanov  wrote:
>> 
>> That looks… “interesting”.
>> So your code is Qt 5.9.5 based?
>> We are currently building against Qt 5.10.1
>> I guess I’ll need to figure out if this works against Qt 5.10.1 as well or
>> if we are better off downgrading overall.
>> Not sure if I want to tackle this for Subsurface 4.8.3 - that sounds like I
>> might be breaking way too many things.
>> 
> 
> i think the code was fine building against 5.9 but they switched to a
> new Qt feature that broke QtConnectivity against older QtBase and 5.11
> was now required.
> that's the only reason i did that switch.

Qt 5.11 is a problem for us because MXE currently is broken for QtWebkit - 
so we could have either BLE or printing/Facebook support. That could be
awkward. I expect that the QtWebkit issue will be resolved eventually, but
I don’t know how soon.

> digging for the exact feature...i cannot find it / i don't remember.
> 
> something else to note here, it seems that Alex hasn't merged the
> `dev` branch in the `wip/win` branch in a while, so if the build fails
> for you we need to ping him.

Ok. I’ll play with this once I have all the test builds out.

>> And on the off chance that this does sound even the least bit critical
>> (because I have been told by others today that I’m a bit grumpy): I am super
>> happy with your progress there. Lack of BLE support on Windows was a huge
>> concern for me and this is awesome. We may not get this for 4.8.3, but we
>> should be able to get “something” out very soon.
>> 
> 
> as said earlier, credit goes to Linus, as he fixed it by fixing the
> support for the other DC (was it a Mares?).

All that means is that you had it working for a while, except that our code was
broken. But the credit for making BLE work with Qt on Windows does clearly
go to you, Lubomir

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 01:18, Lubomir I. Ivanov  wrote:
>>
>
> i think the code was fine building against 5.9 but they switched to a
> new Qt feature that broke QtConnectivity against older QtBase and 5.11
> was now required.


i don't think i got this right on the first attempt.
trying again.

i think it was a case where 5.9.5 was working file for the wip/win
branch, but QtConnectivity started using a new feature (i don't
remember which one) and i tried Qt 5.10.
qmake in 5.10 failed building for me (there is a discussion with
Thiago earlier in this thread about it), so that's why i switched to
QtBase 5.11 and it worked.

i think it's best, instead of trusting my memory, to just try building
the QtConnectivity module from the wip/win branch against the version
of Qt that you currently have (Qt 5.10.1) and see how it goes.
please share error logs, if any.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 29 September 2018 at 01:03, Dirk Hohndel  wrote:
>
>
> That looks… “interesting”.
> So your code is Qt 5.9.5 based?
> We are currently building against Qt 5.10.1
> I guess I’ll need to figure out if this works against Qt 5.10.1 as well or
> if we are better off downgrading overall.
> Not sure if I want to tackle this for Subsurface 4.8.3 - that sounds like I
> might be breaking way too many things.
>

i think the code was fine building against 5.9 but they switched to a
new Qt feature that broke QtConnectivity against older QtBase and 5.11
was now required.
that's the only reason i did that switch.

digging for the exact feature...i cannot find it / i don't remember.

something else to note here, it seems that Alex hasn't merged the
`dev` branch in the `wip/win` branch in a while, so if the build fails
for you we need to ping him.

> And on the off chance that this does sound even the least bit critical
> (because I have been told by others today that I’m a bit grumpy): I am super
> happy with your progress there. Lack of BLE support on Windows was a huge
> concern for me and this is awesome. We may not get this for 4.8.3, but we
> should be able to get “something” out very soon.
>

as said earlier, credit goes to Linus, as he fixed it by fixing the
support for the other DC (was it a Mares?).

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 1:10 PM, Lubomir I. Ivanov  wrote:
> 
>>> Yes indeed. Now how do I add Lubomir's patches to my 
>>> built-from-source-anyway Qt libraries for MXE?
>>> So we can get more people to test "official" binaries?
>>> 
>> 
>> i will post some instructions later today.
>> the changes to make win32-ble to work are part of an official branch.
>> 
> 
> setup know to work:
>> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1
> 
> once the Qt tree is in place this branch has to be fetched:
> http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win 
> 
> 
> cd qtconnectivity
> git fetch origin wip/win:wip/win
> git checkout wip/win
> 
> at this point building Qt should use that branch.
> 
> please mind that i every time i try to rebuild Qt something breaks for
> me, so i'm probably not the best person on giving advise how to build
> Qt.
> 
> here is my windows CMD script for rebuilding + installing only qtconnectivity:
> 
> @echo off
> cls
> echo 
> echo CLEANUP...
> del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth*
> echo BUILDING...
> make -j4 module-qtconnectivity > NUL
> :: make -j4 module-qtdeclarative > NUL
> echo.
> echo 
> echo COPYING...
> copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth*
> C:\bin\qt\5.9.2\mingw53_32\bin\
> copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth*
> C:\bin\qt\5.9.2\mingw53_32\lib\
> copy /y C:\bin\qt\5.9.2\src\qtbase\lib\libQt5Bluetooth*
> C:\bin\qt\5.9.2\mingw53_32\lib\
> 
> 
> Qt5Bluetooth*.dll will be required for Subsurface deployments.

That looks… “interesting”. 
So your code is Qt 5.9.5 based?
We are currently building against Qt 5.10.1 
I guess I’ll need to figure out if this works against Qt 5.10.1 as well or if 
we are better off downgrading overall.
Not sure if I want to tackle this for Subsurface 4.8.3 - that sounds like I 
might be breaking way too many things.

And on the off chance that this does sound even the least bit critical (because 
I have been told by others today that I’m a bit grumpy): I am super happy with 
your progress there. Lack of BLE support on Windows was a huge concern for me 
and this is awesome. We may not get this for 4.8.3, but we should be able to 
get “something” out very soon.

Thanks

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

Re: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?

[Dirk Hohndel]

> On Sep 28, 2018, at 1:11 PM, Jan Mulder  wrote:
> 
> On 9/28/18 6:44 PM, Dirk Hohndel wrote:
>>> On Sep 28, 2018, at 8:36 AM, Jan Mulder  wrote:
>>> 
>>> On 9/28/18 5:24 PM, Dirk Hohndel wrote:
 A rather embarrassing bug in my Shearwater Teric code, Linus' awesome work 
 on Mares BlueLink Pro support,
 The improvements to the mobile UI. The dive computer shortcut buttons.
 Yes, it's a bit of a rush job. But I'm wondering if we could do this.
 Thoughts?
>>> 
>>> With respect to the mobile UI: ACK for a 2.1.4
>>> 
>>> Just push the strings to Transifex to get things translated.
>> Done
> 
> Ok, NL translation is also done.
> 
> BUT: my optimistic view on the mobile UI was wrong. Just found a (massive) 
> bug in the new Kirigami. Just verified this by reverting commit 
> 17ec95e70c3ae58 (to get back to the previous SHA).
> 
> So needed: revert both 17ec95e70c3ae58 and 40766db459b21.
> 
> Bug is related to the page stack and swiping through dives and returning to 
> the list by the breadcrumb (instead of the menu). Sometimes this results in a 
> page that shows both the divelist and the divedetail page on top of each 
> other. Easy to get to a sane state again from that (just select the dive list 
> from the menu), so not a real showstopper, but it look ugly.

UGH.

Ok, reverting those two. I got side-tracked with work and real life but I’m 
hoping to have reviewed what we have committed since 4.8.2 / 2.1.3 so I can 
have reasonable test build for everyone to play with tonight.

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

Re: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?

[Jan Mulder]

On 9/28/18 6:44 PM, Dirk Hohndel wrote:



On Sep 28, 2018, at 8:36 AM, Jan Mulder  wrote:

On 9/28/18 5:24 PM, Dirk Hohndel wrote:

A rather embarrassing bug in my Shearwater Teric code, Linus' awesome work on 
Mares BlueLink Pro support,
The improvements to the mobile UI. The dive computer shortcut buttons.
Yes, it's a bit of a rush job. But I'm wondering if we could do this.
Thoughts?


With respect to the mobile UI: ACK for a 2.1.4

Just push the strings to Transifex to get things translated.


Done


Ok, NL translation is also done.

BUT: my optimistic view on the mobile UI was wrong. Just found a 
(massive) bug in the new Kirigami. Just verified this by reverting 
commit 17ec95e70c3ae58 (to get back to the previous SHA).


So needed: revert both 17ec95e70c3ae58 and 40766db459b21.

Bug is related to the page stack and swiping through dives and returning 
to the list by the breadcrumb (instead of the menu). Sometimes this 
results in a page that shows both the divelist and the divedetail page 
on top of each other. Easy to get to a sane state again from that (just 
select the dive list from the menu), so not a real showstopper, but it 
look ugly.


--jan

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 28 September 2018 at 17:53, Lubomir I. Ivanov  wrote:
> On 28 September 2018 at 17:44, Dirk Hohndel  wrote:
>>
>>> On Sep 28, 2018, at 6:36 AM, Anton Lundin  wrote:
>>>
>>> So, some how we ended up being out of order.
>>>
>>> I would need to look at the libdivecomputer log file to. It might tell
>>> us what actually happened.
>>
>> Yes, that would be good to follow up on
>>
 i guess the biggest point here is that the BTLE Win32 stack works.
>>>
>>> YEY.
>>
>> Yes indeed. Now how do I add Lubomir's patches to my 
>> built-from-source-anyway Qt libraries for MXE?
>> So we can get more people to test "official" binaries?
>>
>
> i will post some instructions later today.
> the changes to make win32-ble to work are part of an official branch.
>

setup know to work:
> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1

once the Qt tree is in place this branch has to be fetched:
http://code.qt.io/cgit/qt/qtconnectivity.git/log/?h=wip/win

cd qtconnectivity
git fetch origin wip/win:wip/win
git checkout wip/win

at this point building Qt should use that branch.

please mind that i every time i try to rebuild Qt something breaks for
me, so i'm probably not the best person on giving advise how to build
Qt.

here is my windows CMD script for rebuilding + installing only qtconnectivity:

@echo off
cls
echo 
echo CLEANUP...
del /q C:\bin\qt\5.9.2\src\qtbase\lib\*Qt5Bluetooth*
echo BUILDING...
make -j4 module-qtconnectivity > NUL
:: make -j4 module-qtdeclarative > NUL
echo.
echo 
echo COPYING...
copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth*
C:\bin\qt\5.9.2\mingw53_32\bin\
copy /y C:\bin\qt\5.9.2\src\qtbase\lib\Qt5Bluetooth*
C:\bin\qt\5.9.2\mingw53_32\lib\
copy /y C:\bin\qt\5.9.2\src\qtbase\lib\libQt5Bluetooth*
C:\bin\qt\5.9.2\mingw53_32\lib\


Qt5Bluetooth*.dll will be required for Subsurface deployments.

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

Re: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?

[Dirk Hohndel]

> On Sep 28, 2018, at 8:36 AM, Jan Mulder  wrote:
> 
> On 9/28/18 5:24 PM, Dirk Hohndel wrote:
>> A rather embarrassing bug in my Shearwater Teric code, Linus' awesome work 
>> on Mares BlueLink Pro support,
>> The improvements to the mobile UI. The dive computer shortcut buttons.
>> Yes, it's a bit of a rush job. But I'm wondering if we could do this.
>> Thoughts?
> 
> With respect to the mobile UI: ACK for a 2.1.4
> 
> Just push the strings to Transifex to get things translated.

Done

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

Re: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?

[Jan Mulder]

On 9/28/18 5:24 PM, Dirk Hohndel wrote:


A rather embarrassing bug in my Shearwater Teric code, Linus' awesome work on 
Mares BlueLink Pro support,
The improvements to the mobile UI. The dive computer shortcut buttons.

Yes, it's a bit of a rush job. But I'm wondering if we could do this.

Thoughts?


With respect to the mobile UI: ACK for a 2.1.4

Just push the strings to Transifex to get things translated.

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

rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?

[Dirk Hohndel]

A rather embarrassing bug in my Shearwater Teric code, Linus' awesome work on 
Mares BlueLink Pro support,
The improvements to the mobile UI. The dive computer shortcut buttons.

Yes, it's a bit of a rush job. But I'm wondering if we could do this.

Thoughts?

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

Re: Mares Smart Dive Computer + Bluelink pro

[Dirk Hohndel]

> On Sep 28, 2018, at 3:51 AM, Fabio Capriati  wrote:
> 
> Linus, you rock!
> It's quite slow but works! Logs and screenshot are attached, with effect of 
> global warming on Mediterranean sea temperature :(

Outstanding.

Time to make a new Subsurface / Subsurface-mobile version available.

/D

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 28 September 2018 at 17:44, Dirk Hohndel  wrote:
>
>> On Sep 28, 2018, at 6:36 AM, Anton Lundin  wrote:
>>
>> So, some how we ended up being out of order.
>>
>> I would need to look at the libdivecomputer log file to. It might tell
>> us what actually happened.
>
> Yes, that would be good to follow up on
>
>>> i guess the biggest point here is that the BTLE Win32 stack works.
>>
>> YEY.
>
> Yes indeed. Now how do I add Lubomir's patches to my built-from-source-anyway 
> Qt libraries for MXE?
> So we can get more people to test "official" binaries?
>
> So cool. So, so cool.

i will post some instructions later today.
the changes to make win32-ble to work are part of an official branch.

>
> (and yes, Lubomir, I'll bring with me next week one of my favorite dive 
> computers as that is a BLE device that's very different from the OSTC that 
> you have...)
>

sounds good.

Steve, did you had a change to test again?
also please share all the logs + dumps so that we can have a look.
thanks.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 28, 2018, at 6:36 AM, Anton Lundin  wrote:
> 
> So, some how we ended up being out of order.
> 
> I would need to look at the libdivecomputer log file to. It might tell
> us what actually happened.

Yes, that would be good to follow up on

>> i guess the biggest point here is that the BTLE Win32 stack works.
> 
> YEY.

Yes indeed. Now how do I add Lubomir's patches to my built-from-source-anyway 
Qt libraries for MXE?
So we can get more people to test "official" binaries?

So cool. So, so cool.

(and yes, Lubomir, I'll bring with me next week one of my favorite dive 
computers as that is a BLE device that's very different from the OSTC that you 
have...)

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Anton Lundin]

On 27 September, 2018 - Lubomir I. Ivanov wrote:

> On 27 September 2018 at 07:16, Steve  wrote:
> >
> > May have spoken too soon.
> > Got an error dialog with "Dive data import error" message
> >
> > Last bit of the cmd window log below:
> 
> thanks a lot for testing!!
> 
> did you try more than once e.g. restarting and trying again?
> it worked nicely for me 2 of 2 times for this OSTC+ unit.
> 
> > QTime("13:36:36.353") packet READ ""
> > read 20
> > QTime("13:36:36.354") packet WAIT
> > QTime("13:36:48.367") packet SEND "ff"
> > read 20
> > QTime("13:36:48.375") packet WAIT
> > QTime("13:36:48.508") packet RECV "4cff"
> > QTime("13:36:48.508") packet READ "4cff"
> > Deleting BLE object
> > Finishing download thread: "Dive data import error"
> > Set the current dive site: 72475123
> > Set the current dive site: 72475123
> >
> 
> this is entering the land of protocols and such in libdivecomputer
> that i don't understand.
> so i'm going to have to defer to others.

Ok. My memory was correct.

The 0xFF command sent is the "EXIT" command, and then we expect the dc
to echo the command back, but we get a extra 0x4c there, before the echo
0xff.

The 0x4c is the S_READY (service mode ready) byte, aka the whole memory
dump was sent.

So, some how we ended up being out of order.

I would need to look at the libdivecomputer log file to. It might tell
us what actually happened.
 
> i guess the biggest point here is that the BTLE Win32 stack works.

YEY.


//Anton


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