Re: reverted marble mess

[Axel Richter]

Am 18.07.2017 um 18:59 schrieb Dirk Hohndel:

On Jul 18, 2017, at 9:41 AM, Axel Richter  wrote:

Am 15.07.2017 um 07:53 schrieb Dirk Hohndel:

Since Tomaz hasn't had the time to fix the broken marble source (and
currently builds from source were failing) I reverted the merge of his
changes. Of course that means I need to be extra careful to handle this
branch moving forward, because if we decide to do this merge after all, I
first need to revert the revert. If this seems strange, read
https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt
for explanation from the master's mouth (or fingers).

In the mean time, builds should work again.

Hi Dirk,

thank a lot for your 'early morning commit'. Its better now, but how can I 
prevent marble from needing Qt5WebKitWidgets?

That's the reason why Tomaz wanted to update Marble, but why we are
in the end moving away from Marble. The older version we use requires
WebKit. Most Linux distributions still ship that - but if your distro doesn't,
then you'll have to either build Qt5WebKit from source, or disable Marble.

/D


Hi Dirk,

I'll wait and see what comes up. QLocation is definitely the 
better idea.


Thanks a lot for your work and effort,

Axel.


--
Axel Richter

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

Re: QML custom style

[Joakim Bygdell]

On 18 July 2017 at 22:10, Rick Walsh  wrote:

> Dirk and Jocke (especially),
> I can see you've done a lot over the past few weeks to make the mobile UI
> much more attracted.  Have you considered using a custom Subsurface style
> (falling back to Material) to make it more efficient to theme the QML
> controls?  It would be easier to customize the controls in one place, and
> have the change made consistently throughout, following the guidance in:
> https://doc.qt.io/qt-5/qtquickcontrols2-customize.
> html#creating-a-custom-style
>

The thing is that we are not just dealing with the material theme here,
Kirigami has it own theme as well.
And the interaction between these two are in some cases a bit special as
there are parts where the material theme decides what the user sees and
other parts where the Kirigami decides how things will look.
Right now we just tell the app that for material light theme to set a few
parameters to our own colors, the rest is actually handled by the Kirigami
theme.


>
> In the attached patch I have done that for the button controls (only used
> on DownloadFromDiveComputer.qml) moving the styling into
> SubsurfaceStyle/Button.qml, but it would not be hard to do it for the other
> controls.  Using the Button as an example, we could then add code to make
> the button depress and change colour when down, and only have to add the
> code in one place.
>
> The big problem now, is that the only way I've been able to use the custom
> style is to select it from the command line (testing on desktop):
> ./subsurface-mobile -style /home/rick/src/subsurface/mobile-widgets/qml/
> SubsurfaceStyle
> Clearly that is useless for the mobile app.  I believe we should also be
> able to use QQuickStyle::SetStyle to set it from within the app (see
> https://doc.qt.io/qt-5/qquickstyle.html), but the following doesn't work
> for me, either with or with setting the fallback style.  Maybe the problem
> is that I'm using Qt5.7, but I'm not sure.
>
> diff --git a/subsurface-mobile-helper.cpp b/subsurface-mobile-helper.cpp
> index 68dd228b..cd1df6c6 100644
> --- a/subsurface-mobile-helper.cpp
> +++ b/subsurface-mobile-helper.cpp
> @@ -14,6 +14,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -43,6 +44,10 @@ void run_ui()
> qmlRegisterType("org.subsurfacedivelog.mobile",
> 1, 0, "DCDownloadThread");
> qmlRegisterType("org.subsurfacedivelog.mobile",
> 1, 0, "DCImportModel");
>
> +   // set style for custom constrols
> +   QQuickStyle::setStyle(":/SubsurfaceStyle");
> +   QQuickStyle::setFallbackStyle("Material");
> +
> QQmlApplicationEngine engine;
> KirigamiPlugin::getInstance().registerTypes();
>  #if __APPLE__
>
> Cheers,
>
> Rick
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>


-- 

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

QML custom style

[Rick Walsh]

Dirk and Jocke (especially),
I can see you've done a lot over the past few weeks to make the mobile UI
much more attracted.  Have you considered using a custom Subsurface style
(falling back to Material) to make it more efficient to theme the QML
controls?  It would be easier to customize the controls in one place, and
have the change made consistently throughout, following the guidance in:
https://doc.qt.io/qt-5/qtquickcontrols2-customize.html#creating-a-custom-style

In the attached patch I have done that for the button controls (only used
on DownloadFromDiveComputer.qml) moving the styling into
SubsurfaceStyle/Button.qml, but it would not be hard to do it for the other
controls.  Using the Button as an example, we could then add code to make
the button depress and change colour when down, and only have to add the
code in one place.

The big problem now, is that the only way I've been able to use the custom
style is to select it from the command line (testing on desktop):
./subsurface-mobile -style
/home/rick/src/subsurface/mobile-widgets/qml/SubsurfaceStyle
Clearly that is useless for the mobile app.  I believe we should also be
able to use QQuickStyle::SetStyle to set it from within the app (see
https://doc.qt.io/qt-5/qquickstyle.html), but the following doesn't work
for me, either with or with setting the fallback style.  Maybe the problem
is that I'm using Qt5.7, but I'm not sure.

diff --git a/subsurface-mobile-helper.cpp b/subsurface-mobile-helper.cpp
index 68dd228b..cd1df6c6 100644
--- a/subsurface-mobile-helper.cpp
+++ b/subsurface-mobile-helper.cpp
@@ -14,6 +14,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,10 @@ void run_ui()
qmlRegisterType("org.subsurfacedivelog.mobile", 1,
0, "DCDownloadThread");
qmlRegisterType("org.subsurfacedivelog.mobile",
1, 0, "DCImportModel");

+   // set style for custom constrols
+   QQuickStyle::setStyle(":/SubsurfaceStyle");
+   QQuickStyle::setFallbackStyle("Material");
+
QQmlApplicationEngine engine;
KirigamiPlugin::getInstance().registerTypes();
 #if __APPLE__

Cheers,

Rick
From 5b517f4f036e9532406954b106b543de77ae5da3 Mon Sep 17 00:00:00 2001
From: Rick Walsh 
Date: Wed, 19 Jul 2017 07:49:11 +1200
Subject: [PATCH] QML: Create and use new SubsurfaceStyle for button controls

Signed-off-by: Rick Walsh 
---
 mobile-widgets/qml/DownloadFromDiveComputer.qml | 45 -
 mobile-widgets/qml/SubsurfaceStyle/Button.qml   | 29 
 2 files changed, 29 insertions(+), 45 deletions(-)
 create mode 100644 mobile-widgets/qml/SubsurfaceStyle/Button.qml

diff --git a/mobile-widgets/qml/DownloadFromDiveComputer.qml b/mobile-widgets/qml/DownloadFromDiveComputer.qml
index 9086a2e0..96d94c06 100644
--- a/mobile-widgets/qml/DownloadFromDiveComputer.qml
+++ b/mobile-widgets/qml/DownloadFromDiveComputer.qml
@@ -145,16 +145,7 @@ Kirigami.Page {
 		RowLayout {
 			Button {
 id: download
-background: Rectangle {
-	color: subsurfaceTheme.darkerPrimaryColor
-	antialiasing: true
-	radius: Kirigami.Units.smallSpacing * 2
-}
 text: qsTr("Download")
-contentItem: Text {
-	text: download.text
-	color: subsurfaceTheme.darkerPrimaryTextColor
-}
 onClicked: {
 	text = qsTr("Retry")
 	if (downloadThread.deviceData.bluetoothMode) {
@@ -177,16 +168,7 @@ Kirigami.Page {
 			}
 			Button {
 id:quitbutton
-background: Rectangle {
-	color: subsurfaceTheme.darkerPrimaryColor
-	antialiasing: true
-	radius: Kirigami.Units.smallSpacing * 2
-}
 text: qsTr("Quit")
-contentItem: Text {
-	text: quitbutton.text
-	color: subsurfaceTheme.darkerPrimaryTextColor
-}
 onClicked: {
 	manager.appendTextToLog("exit DCDownload screen")
 	stackView.pop();
@@ -230,16 +212,7 @@ Kirigami.Page {
 			Button {
 id: acceptButton
 enabled: divesDownloaded
-background: Rectangle {
-	color: enabled ? subsurfaceTheme.darkerPrimaryColor : "gray"
-	antialiasing: true
-	radius: Kirigami.Units.smallSpacing * 2
-}
 text: qsTr("Accept")
-contentItem: Text {
-	text: acceptButton.text
-	color: subsurfaceTheme.darkerPrimaryTextColor
-}
 onClicked: {
 	manager.appendTextToLog("Save downloaded dives that were selected")
 	importModel.recordDives()
@@ -256,16 +229,7 @@ Kirigami.Page {
 			Button {
 id: select
 enabled: divesDownloaded
-background: Rectangle {
-	color: enabled ? subsurfaceTheme.darkerPrimaryColor : "gray"
-	antialiasing: true
-	radius: Kirigami.Units.smallSpacing * 2
-}
 text: qsTr("Select All")
-contentItem: Text {
-	text: select.text
-	color: subsurfaceTheme.darkerPrimaryTextColor
-}
 onClicked : {
 	selectAll = true
 	importModel.selectAll()
@@ -274,16 +238,7 @@ Kirigami.Page {
 			Button {
 id: unselect
 enabled: divesDownloaded
-

Re: Pull request

[Willem Ferguson]

On 18/07/2017 21:43, Dirk Hohndel wrote:


The manual that you get when you click the link is the one posted on the website - 
which is the "old' one indeed.
But the sources already contain a much updated manual.

I could try and post a Subsurface-mobile-v2 user manual on the website (built 
from the latest sources) and have that displayed when using Subsurface-mobile 2

/D


I made several of the images a bit smaller and I want to see whether I 
overdid this. I have no idea how WordPress handles the sizes of the images.


Would you please have a look at the attached screen from Github? I think 
what it says is "You fool, the source repo already has all the changes 
in your manual-branch. It makes no sense to generate a pull request". Is 
this correct?


That probably explains a lack of pr on your side.

Kind regards,

willem


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

Re: Pull request

[Dirk Hohndel]

> On Jul 18, 2017, at 12:24 PM, Willem Ferguson 
>  wrote:
> 
> On 18/07/2017 18:10, Dirk Hohndel wrote:
>> Hmm, I don't even understand the question.
>> 
>> I haven't seen a pull request, but you sent me email to pull from the 
>> separate git repo that you
>> shared with me a while ago. Are there other changes I need to pull? Where 
>> are they?
> I will sort out the pull request. I suspect the request went to the 
> maintainer of the local repo..->me and not to the maintainer of the source 
> repo.
> I am happy to do what I can to have the manual ready. I am at home until the 
> 28th, after which I am moving around a lot until end Aug.
> The current manual with 4.6.4.432 is still the old version before any 
> changes. Give me a bit of time to sort the pr out.

The manual that you get when you click the link is the one posted on the 
website - which is the "old' one indeed.
But the sources already contain a much updated manual.

I could try and post a Subsurface-mobile-v2 user manual on the website (built 
from the latest sources) and have that displayed when using Subsurface-mobile 2

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

Re: Issues with SAC terminology

[James Cialdea]

On Tue, Jul 18, 2017 at 2:14 PM, Dirk Hohndel  wrote:

> Remember, we always show the unit (l/min or cuft/min), so it's clear that SAC 
> isn't a pressure drop.

Side note - In the mobile app, I see only "cuft", not "cuft/min".
Clearly, the numbers being shown are "cuft/min" - I definitely consume
more than .47cuft of air on a 49min@60ft OC dive. :)

I agree that the terms are a bit fuzzy in their colloquial usage, but
I do not recall SAC being used in any documentation referring to
volume per time.  Sure, people talk about "consumption" and sometimes
improperly use the term "SAC", but people also use "good" where they
should use "well" - it doesn't make it right.  I was surprised to see
"SAC" associated with volume per time when I started using Subsurface,
but the displayed unit does make it clear what is being discussed (at
least on the desktop application).

The way SAC has been explained to me is that it is tank specific, but
depth adjusted.  This makes it useful for "how much time can I spend
at X depth with Y tank?" but not for "was I breathing hard?"  For that
question, I've used the RMV (Respiratory Minute Volume) term, the
calculation of which is neither tank nor depth specific, as it uses a
volume that is normalized to the ambient pressure at depth.  I've also
heard RMV called SCR (Surface Consumption Rate) or SACR (Surface Air
Consumption Rate or SAC Rate).

For reference, the SSI definition of SAC (imperial units) is:

SAC = [( PSI / T ) * 33ft] / [D + 33ft]
where:
PSI = Gas consumption (PSI)
T = Time (min)
D = Depth (ft)
SAC => PSI/min

This neat NAUI calculator is using a similar formula, but I couldn't
find an official reference:
http://www.scuba.com/scuba-gear-120/058048/NAUI-Scuba-Dive-Calculator-Surface-Air-Consumption.html

I wasn't able to find an official reference for PADI, either.

Here's an SDI/TDI article using the same formula:
https://www.tdisdi.com/air-management-and-the-importance-of-learning-surface-air-consumption-rate-sac/

Those bodies aside, Google searches for calculating SAC seems to line
up with the formula above (and its metric equivalent).

>
> /D
> ___
> 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: Pull request

[Willem Ferguson]

On 18/07/2017 18:10, Dirk Hohndel wrote:

Hmm, I don't even understand the question.

I haven't seen a pull request, but you sent me email to pull from the 
separate git repo that you
shared with me a while ago. Are there other changes I need to pull? 
Where are they?
I will sort out the pull request. I suspect the request went to the 
maintainer of the local repo..->me and not to the maintainer of the 
source repo.
I am happy to do what I can to have the manual ready. I am at home until 
the 28th, after which I am moving around a lot until end Aug.
The current manual with 4.6.4.432 is still the old version before any 
changes. Give me a bit of time to sort the pr out.


Kind regards,
willem

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

Re: Issues with SAC terminology

[Dirk Hohndel]

> On Jul 18, 2017, at 11:11 AM, Willem Ferguson 
>  wrote:
> 
> On 18/07/2017 19:14, Linus Torvalds wrote:
>> 
>> Absolutely *everybody* knows what we mean by SAC rate. And the ones
>> that are offended by our use of standard terminology can be offended.
>> 
>> It's their problem, not ours. Let's not take on their mental baggage.
>> 
>> Linus
>> 
> Part of this argument is just me and who I am. I am a scientist and for 
> effective communication, terminology is critical. Just look how he word 
> "awesome" has totally lost its meaning in popular language: it can mean 
> almost anything. My students have lost the meaning of the word "variation" or 
> the verb "vary": they would say that men vary from women, not that men differ 
> from women, so the word "variation" has lost its technical meaning. In 
> addition, I was trained that each number one uses has an associated unit. To 
> say that respiratory minute volume is measured in bar is just nonsensical. 
> And we use this common-day terminology in situations where people can get 
> hurt by miscommunication or misperception.
> 
> But clearly I am far in the minority, so I will shut my mouth on this issue.

I think you actually agree with Linus and me - mostly. We all bemoan the 
confusion in terminology. The one thing we disagree about is whether there is 
value in trying to find a term different from SAC that people will grasp.
Remember, we always show the unit (l/min or cuft/min), so it's clear that SAC 
isn't a pressure drop.

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

Re: Issues with SAC terminology

[Willem Ferguson]

On 18/07/2017 19:14, Linus Torvalds wrote:


Absolutely *everybody* knows what we mean by SAC rate. And the ones
that are offended by our use of standard terminology can be offended.

It's their problem, not ours. Let's not take on their mental baggage.

 Linus

Part of this argument is just me and who I am. I am a scientist and for 
effective communication, terminology is critical. Just look how he word 
"awesome" has totally lost its meaning in popular language: it can mean 
almost anything. My students have lost the meaning of the word 
"variation" or the verb "vary": they would say that men vary from women, 
not that men differ from women, so the word "variation" has lost its 
technical meaning. In addition, I was trained that each number one uses 
has an associated unit. To say that respiratory minute volume is 
measured in bar is just nonsensical. And we use this common-day 
terminology in situations where people can get hurt by miscommunication 
or misperception.


But clearly I am far in the minority, so I will shut my mouth on this issue.

Kind regards,

willem


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

Re: [Subsurface-divelog/subsurface] [idea] Mobile UI #5: sidebar (#430)

[Davide DB]

Sorry for too quoting.

I'm with Dirk here.
I would trilled to see a planner and maybe a gas mixer but as a standalone
app planner+mixer.
As on the stats feature I would prefer a more KISS approach. I don't like a
swiss knife approach aka do it all.

On menu size. Don't worry we can scroll it. Look at my feedly menu:

https://youtu.be/ZEIdIkm3aa0

IMHO the most future proof feature is having with kirigami a menu like that
(I used it in my design). A menu which doesn't waste horizontal space.

PS
Willem what I forgot in the GPS menu?


davide@mobile

On Jul 18, 2017 7:44 PM, "Dirk Hohndel"  wrote:

> I am very intentionally moving  this small part of the discussion around
> Davide's Mobile UI ideas back to the developer mailing list because I think
> it is important - and not a lot of the people here tend to look at the
> issues on github (that's the eternal problem... it's hard to discuss these
> things in email and they get forgotten too easily if we do, yet there is a
> lot less participation on github...)
>
>
> On Jul 18, 2017, at 10:30 AM, willemferguson 
> wrote:
>
> Just look at the items in the Desktop Main Menu, Things like "Filter",
> Renumber dive list, Edit device names, Configure DC, und so weiter und so
> weiter.
>
>
> So just to repeat something that I've said many times and that everyone
> loves to just not hear or ignore...
> We. Will. Not. Recreate. The desktop app. As. Mobile app.
>
> Filter? Maybe. Because that is super useful.
>
> Renumber, edit device names, configure DC, all that other junk we have
> there? Nope. Please. Nope.
>
> Several of these items are likely to find their way into mobile and space
> needs to be available to build them into the menu system. Already I am not
> convinced that the whole menu system will fit onto a single mobile screen.
> Rather than an ad hoc solution such as "Tools", a more fundamental and
> pro-active plan needs to be made. Even if there is a Tools item in the
> present menu system (and Davide has forgotten at least one more menu item,
> Show GPS locations), the list is already too long for an average mobile
> phone
>
>
> Yes. And the fix is not to try to have every silly thing in there. I am
> still not convinced that I want to take the planner code. Seriously, start
> a Subsurface-mobile-planner app.
> All adding a planner will do is to add complexity, add more settings, add
> more things that will break, make the app bigger. And sure, fifteen people
> will each use it once. Seven will use it a few times. And three people will
> use it every week for the rest of their lives. And the other 2000 users
> will never even open the menu.
>
> Our current planner is a disgusting mess of a UI on a 15" laptop screen
> with keyboard / mouse interaction.
> But we are spending time on making it work with a tap based UI on a 5"
> screen. Sure.
>
> Could we instead try to fix the actual mobile app instead? I am thrilled
> that a couple more people have started to work on the QML code. YAY.
> Let's not distract ourselves again.
>
> /D
>
>
> ___
> 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: [Subsurface-divelog/subsurface] [idea] Mobile UI #5: sidebar (#430)

[Dirk Hohndel]

I am very intentionally moving  this small part of the discussion around 
Davide's Mobile UI ideas back to the developer mailing list because I think it 
is important - and not a lot of the people here tend to look at the issues on 
github (that's the eternal problem... it's hard to discuss these things in 
email and they get forgotten too easily if we do, yet there is a lot less 
participation on github...)


> On Jul 18, 2017, at 10:30 AM, willemferguson  wrote:
> Just look at the items in the Desktop Main Menu, Things like "Filter", 
> Renumber dive list, Edit device names, Configure DC, und so weiter und so 
> weiter.
> 

So just to repeat something that I've said many times and that everyone loves 
to just not hear or ignore...
We. Will. Not. Recreate. The desktop app. As. Mobile app.

Filter? Maybe. Because that is super useful.

Renumber, edit device names, configure DC, all that other junk we have there? 
Nope. Please. Nope.
> Several of these items are likely to find their way into mobile and space 
> needs to be available to build them into the menu system. Already I am not 
> convinced that the whole menu system will fit onto a single mobile screen. 
> Rather than an ad hoc solution such as "Tools", a more fundamental and 
> pro-active plan needs to be made. Even if there is a Tools item in the 
> present menu system (and Davide has forgotten at least one more menu item, 
> Show GPS locations), the list is already too long for an average mobile phone
> 

Yes. And the fix is not to try to have every silly thing in there. I am still 
not convinced that I want to take the planner code. Seriously, start a 
Subsurface-mobile-planner app.
All adding a planner will do is to add complexity, add more settings, add more 
things that will break, make the app bigger. And sure, fifteen people will each 
use it once. Seven will use it a few times. And three people will use it every 
week for the rest of their lives. And the other 2000 users will never even open 
the menu.

Our current planner is a disgusting mess of a UI on a 15" laptop screen with 
keyboard / mouse interaction.
But we are spending time on making it work with a tap based UI on a 5" screen. 
Sure.

Could we instead try to fix the actual mobile app instead? I am thrilled that a 
couple more people have started to work on the QML code. YAY.
Let's not distract ourselves again.

/D

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

Re: Issues with SAC terminology

[John Van Ostrand]

On Tue, Jul 18, 2017 at 9:54 AM, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> This is in some ways a sensitive issue and maybe reflect existing
> discussion on this mail list that I am not aware of. The term "Surface Air
> Consumption" (SAC) is probably used wrongly most of the time, including by
> myself. This is because it is conflated with the Respiratory Minute Volume
> (RMV). Since, in our broad way of talking, we measure SAC as cu ft/minute
> or liters/minute, this is the volume that is referenced and should more
> accurately be indicated as RMV. SAC rate is a pressure indication, the
> number of bars of gas used per minute and not a volume. Corrected for
> cylinder size, it allows calculation of RMV. This is also consistent with
> the NAUI and IANTD training materials that I have contact with. Shouldn't
> we at some stage get the terminology accurate and replace SAC in the UI
> throughout with RMV?
>

There doesn't seem to be a consensus in tech diving how SAC and RMV are
defined. At one time I was told SAC is pressure change and RMV is volume
consumed, both representing consumption at 1 ATM. The manual from the Adv
Trimix course I just took from TDI said SAC is the volume of gas consumed
at 1 ATM and RMV is volume of gas used at a certain depth.

The common spoken (informal) usage among pre-tech divers in my experience
is that SAC is volume consumed at 1 ATM. From my limited tech experience
the most common use is of SAC as pressure and RMV as volume both at 1 ATM.

Personally I think think pressure change is pointless as anything but an
intermediate metric since it relies on the tank specs on which it was based
on. SAC as volume is the metric to keep in mind when planning dives and RMV
is the target metric to use when planning real world gas usage.



-- 
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: Issues with SAC terminology

[Dirk Hohndel]

> On Jul 18, 2017, at 10:18 AM, Linus Torvalds  
> wrote:
> 
> On Tue, Jul 18, 2017 at 10:14 AM, Linus Torvalds
>  wrote:
>> 
>> Absolutely *everybody* knows what we mean by SAC rate. And the ones
>> that are offended by our use of standard terminology can be offended.
> 
> The takeaway here really is that even the people who have have their
> hangups about this know what we mean, so nobody is ever actively
> confused.

THIS.

We may not use the term that they prefer (AMV, RMV, SGC, SGR, SCR,
I'm sure there are more). But no one can seriously claim to not understand
what Subsurface is giving them under the term SAC.

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

Re: Issues with SAC terminology

[Linus Torvalds]

On Tue, Jul 18, 2017 at 10:14 AM, Linus Torvalds
 wrote:
>
> Absolutely *everybody* knows what we mean by SAC rate. And the ones
> that are offended by our use of standard terminology can be offended.

The takeaway here really is that even the people who have have their
hangups about this know what we mean, so nobody is ever actively
confused.

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

Re: Issues with SAC terminology

[Linus Torvalds]

On Tue, Jul 18, 2017 at 6:54 AM, Willem Ferguson
 wrote:
>
> Shouldn't we  at some stage get the terminology accurate and replace SAC in
> the UI throughout with RMV?

No, I really don't think so.

The scuba world has a lot of random terminology that may be mis-used,
but is effectively standard. SAC is just one o those things.

The fact is, everybody uses "SAC" the way we do. Yes, yes, yes, some
training material says that that is the "sit in chair for 20 minutes"
volume, but let's face it, that's just a stupid training thing, and
even then it's just a single-time explanatory exercise (or not even
single-time).

The "sit in a chair and test your actual surface consumption" thing is
completely meaningless.

So everybody just uses SAC and RMV entirely interchangeably, with some
people apparently even using SRMV (where the "S" is to clarify that
it's translated to surface equivalents rather than being
depth-dependent).

And then some people talk about "bar per minute" for a particular
tank, just because then they can allegedly just do the mental
calculation depending on depth.

It's all purely BS. Some crazy tech diver that has the "there is only
one correct way" mode of diving will have their particular very strong
opinions of exactly what each particular TLA means, but it's all
pointless.

In the end, SAC is just the most common thing to use, and we use it
the way everybody uses it in practice, simply because the "other"
possible meaning of SAC is completely pointless and nobody ever really
talks about it.

I am very against the pointless "pilkunnussija" culture of some tech
divers, that try to define things in particular ways that make no
sense. Let's use accepted normal *common* language rather than
anything else.

Absolutely *everybody* knows what we mean by SAC rate. And the ones
that are offended by our use of standard terminology can be offended.

It's their problem, not ours. Let's not take on their mental baggage.

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

Re: QML UI theming

[Joakim Bygdell]

Patches sent to upstream Kirigami.


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

Re: Issues when editing a downloaded dive from DC

[Jan Mulder]

On 18-07-17 18:41, Chirana Gheorghita Eugeniu Theodor wrote:

Does anyoane here has the same issue or I am the only one?

On Jul 17, 2017 23:30, "Chirana Gheorghita Eugeniu Theodor" 
> wrote:


Ahoy list,
This is my first message here so I wish to say hello to all users
and a big thank you to developers.
I recently downloaded a dive from my dc , a tusa zen iq-900, using
the mobile app on Android. All ok. I completed all dive details
using a windows pc (weight, air temp, gps location, tank etc...) All
ok , dive was saved corectly to cloud.
Now because it was a altitude dive and from my dc Subsurface does
not read altitude, even if the dc adjusts automaticly, i entered in
the edit dive in dive planner , selected the proper altitude and
saved the dive.
Issue is that temperature data is lost (before the edit it was shown
in graph).

> Am I missing a setting in Subsurface?

I can confirm this issue. However, the big question is whether it needs 
to be repaired. The planner is not intended to adapt all data from a 
real executed dive. You even get a warning "Trying to replan a dive that 
is not a planned dive" before you try. Also the profile gets "simplied" 
(obviously, because you do not want to plan a dive with a 2 second 
interval of the samples from the dive computer). So basically, you are 
touching a use case that is never intended functionality.


This all said. The question remains: why can the air pressure not be 
edited on an executed dive? Just like the Air/Water temperatures.



I also observed on another dive with deco, after adding the tank
exchange (using windows app) the red bar (dc reported ceiling)
dissapeared.


I cannot reproduce this (assuming you are talking about the normal view, 
so not the planner. I use this (adding a deco gas) a lot, and have not 
seen this ever.


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

Re: reverted marble mess

[Dirk Hohndel]

> On Jul 18, 2017, at 9:41 AM, Axel Richter  wrote:
> 
> Am 15.07.2017 um 07:53 schrieb Dirk Hohndel:
>> Since Tomaz hasn't had the time to fix the broken marble source (and
>> currently builds from source were failing) I reverted the merge of his
>> changes. Of course that means I need to be extra careful to handle this
>> branch moving forward, because if we decide to do this merge after all, I
>> first need to revert the revert. If this seems strange, read
>> https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt
>> for explanation from the master's mouth (or fingers).
>> 
>> In the mean time, builds should work again.
> 
> Hi Dirk,
> 
> thank a lot for your 'early morning commit'. Its better now, but how can I 
> prevent marble from needing Qt5WebKitWidgets?

That's the reason why Tomaz wanted to update Marble, but why we are 
in the end moving away from Marble. The older version we use requires
WebKit. Most Linux distributions still ship that - but if your distro doesn't,
then you'll have to either build Qt5WebKit from source, or disable Marble.

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

Re: reverted marble mess

[Axel Richter]

Am 15.07.2017 um 07:53 schrieb Dirk Hohndel:

Since Tomaz hasn't had the time to fix the broken marble source (and
currently builds from source were failing) I reverted the merge of his
changes. Of course that means I need to be extra careful to handle this
branch moving forward, because if we decide to do this merge after all, I
first need to revert the revert. If this seems strange, read
https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt
for explanation from the master's mouth (or fingers).

In the mean time, builds should work again.

And if we are lucky, Lubomir will be successful with the QtLocation
changes and we can just forget Marble.




Hi Dirk,

thank a lot for your 'early morning commit'. Its better 
now, but how can I prevent marble from needing 
Qt5WebKitWidgets?


Thanks,

Axel.



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

Re: reverted marble mess

[Axel Richter]

Am 15.07.2017 um 07:53 schrieb Dirk Hohndel:

Since Tomaz hasn't had the time to fix the broken marble source (and
currently builds from source were failing) I reverted the merge of his
changes. Of course that means I need to be extra careful to handle this
branch moving forward, because if we decide to do this merge after all, I
first need to revert the revert. If this seems strange, read
https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt
for explanation from the master's mouth (or fingers).

In the mean time, builds should work again.


Hi Dirk,

thank a lot for your 'early morning commit'. Its better now, 
but how can I prevent marble from needing Qt5WebKitWidgets?


Thanks,

Axel.

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

Re: Issues when editing a downloaded dive from DC

[Chirana Gheorghita Eugeniu Theodor]

Does anyoane here has the same issue or I am the only one?

On Jul 17, 2017 23:30, "Chirana Gheorghita Eugeniu Theodor" <
off...@adaptcom.ro> wrote:

> Ahoy list,
> This is my first message here so I wish to say hello to all users and a
> big thank you to developers.
> I recently downloaded a dive from my dc , a tusa zen iq-900, using the
> mobile app on Android. All ok. I completed all dive details using a windows
> pc (weight, air temp, gps location, tank etc...) All ok , dive was saved
> corectly to cloud.
> Now because it was a altitude dive and from my dc Subsurface does not read
> altitude, even if the dc adjusts automaticly, i entered in the edit dive in
> dive planner , selected the proper altitude and saved the dive.
> Issue is that temperature data is lost (before the edit it was shown in
> graph).
> Am I missing a setting in Subsurface?
> I also observed on another dive with deco, after adding the tank exchange
> (using windows app) the red bar (dc reported ceiling) dissapeared.
>
> Regards,
> Theodor
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: mysterious code (qtserialbleutooth.cpp)

[Linus Torvalds]

On Jul 18, 2017 06:49, "Jan Mulder"  wrote:


Is the typo in the #define intentional?


Nope, absolutely not intentional.

And where is the actual value defined?


I have no idea. Apparently BUFSZ we just too randomly generic of a name
that it matched some other common historical define by mistake when
mistyped that at pick up from some random header file. Just pick something
else.

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

Re: Mobile UI Sidebar and Settings

[Dirk Hohndel]

> On Jul 18, 2017, at 6:53 AM, Davide DB  wrote:
> 
> I worked on two of the three parts of the current Subsurface that IMHO
> I feel need more work.
> 
> - Sidebar
> - Settings
> 
> I left the "edit dive details" as next last effort.
> 
> https://github.com/Subsurface-divelog/subsurface/issues/430#issuecomment-316069183

I love the way the layouts look. I agree with you that this wasn't designed at 
all but grew
helter skelter without a lot of grown up supervision...

I'll comment on the issue.

> Please Dirk, be calm with your Hattori Hanzo's Sword for a while.



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

RE: BLE on iOS

[Alex Blasche]

> -Original Message-
> From: Dirk Hohndel [mailto:d...@hohndel.org]

> I don't want to sound like a downer... but I must have missed that 
> explanation in
> the documentation. It would be kinda neat if the classes had a little warning 
> that
> said "this doesn't work on iOS - implementation is a dummy". Looking at
> http://doc.qt.io/qt-5/qbluetoothlocaldevice.html I can't find any indication 
> that
> I wouldn't be able to start with this...

Indeed, we have to fix this.

> Thanks for the help - I can virtually assure you that I'll be back with more
> questions. I assume that the documentation is maintained in git somewhere as
> well. As I work through this, should I try to propose changes to the docs? 
> Where
> would I start to create pull requests for that?

Those contributions happen via gerrit on codereview.qt-project.org. The general 
process description can be found on 
http://wiki.qt.io/Qt_Contribution_Guidelines. Timur or myself can help as well.

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

Re: BLE on iOS

[Timur Pocheptsov]

Hello,


> Excellent. So we can bug him for both iOS and Mac? :-)


Yes 


> That's one of the things that puzzle me. It says the same about macOS in the 
> documentation, yet we do get Bluetooth addresses on macOS - just not 100% 
> reliably.


Apple has two frameworks actually - IOBluetooth (to deal with Bluetooth 
'classic') and more recent CoreBluetooth (BLE).

CoreBluetooth works with UUIDs, but IOBluetooth - indeed exposes addresses.


Best regards,

Timur.


From: Dirk Hohndel 
Sent: Tuesday, July 18, 2017 3:34:50 PM
To: Alex Blasche
Cc: Subsurface; Timur Pocheptsov
Subject: Re: BLE on iOS

Hi Alex, Timur,

> On Jul 18, 2017, at 4:09 AM, Alex Blasche  wrote:
>> Nor sure if you are the right person for this on iOS - but if not, maybe you 
>> can
>> point me to the right person.
>
> Timur (in cc) is the Apple master for QtBluetooth.

Excellent. So we can bug him for both iOS and Mac? :-)

>> When compiling Subsurface-mobile for iOS with BT_SUPPORT enabled, we don't
>> appear to get a valid QBluetoothLocalDevice at all. Asking for isValid() 
>> returns
>> false, asking for allDevices() returns an empty list.
>> I tried powerOn() but as expected that doesn't work, either.
>
> QBluetoothLocalDevice is not possible on iOS. Apple does not expose this 
> information to app developers. The classes implementation is a dummy only. 
> The same is true for QBluetoothServer, QBluetoothSocket, 
> QBluetoothServiceDiscoveryAgent. Only the straight path to 
> QLowEnergyController (BTLE use cases) are supported. That means that only the 
> following class chain works:
>
> QBluetoothDeviceDiscoveryAgent -> QBluetoothDeviceInfo -> QLowEnergyController

I don't want to sound like a downer... but I must have missed that explanation 
in the documentation. It would be kinda neat if the classes had a little 
warning that said "this doesn't work on iOS - implementation is a dummy". 
Looking at http://doc.qt.io/qt-5/qbluetoothlocaldevice.html I can't find any 
indication that I wouldn't be able to start with this...

Let's start a new #ifdef'ed path with the class chain you suggest.

> Also note, that iOS does not expose Bluetooth addresses. The platform 
> generates uuid's as id's for devices.

That's one of the things that puzzle me. It says the same about macOS in the 
documentation, yet we do get Bluetooth addresses on macOS - just not 100% 
reliably.

Anyway, I'll worry about macOS next, right now I'd love to see some sign of 
life on iOS...

Thanks for the help - I can virtually assure you that I'll be back with more 
questions. I assume that the documentation is maintained in git somewhere as 
well. As I work through this, should I try to propose changes to the docs? 
Where would I start to create pull requests for that?

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

Issues with SAC terminology

[Willem Ferguson]

This is in some ways a sensitive issue and maybe reflect existing 
discussion on this mail list that I am not aware of. The term "Surface 
Air Consumption" (SAC) is probably used wrongly most of the time, 
including by myself. This is because it is conflated with the 
Respiratory Minute Volume (RMV). Since, in our broad way of talking, we 
measure SAC as cu ft/minute or liters/minute, this is the volume that is 
referenced and should more accurately be indicated as RMV. SAC rate is a 
pressure indication, the number of bars of gas used per minute and not a 
volume. Corrected for cylinder size, it allows calculation of RMV. This 
is also consistent with the NAUI and IANTD training materials that I 
have contact with. Shouldn't we at some stage get the terminology 
accurate and replace SAC in the UI throughout with RMV?

Kind regards,
willem


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

Mobile UI Sidebar and Settings

[Davide DB]

I worked on two of the three parts of the current Subsurface that IMHO
I feel need more work.

- Sidebar
- Settings

I left the "edit dive details" as next last effort.

https://github.com/Subsurface-divelog/subsurface/issues/430#issuecomment-316069183

Please Dirk, be calm with your Hattori Hanzo's Sword for a while.

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

mysterious code (qtserialbleutooth.cpp)

[Jan Mulder]

Struggling with BLE for OSTC I see a little mysterious code fragment:

#define BUFSZ 1024
static struct {
unsigned int out_bytes, in_bytes, in_pos;
unsigned char in[BUFSIZ];
unsigned char out[BUFSIZ];
} buffer;

As it is from Linus, I do not dare to change it right away :-)

Is the typo in the #define intentional? And where is the actual value 
defined? I see that on Android it has a value 1024, and on Linux 8192 
(bytes), so some system include I assume.


That 1K value on Android causes my BLE for OSTC to fail as the parser 
wants to pull 1K blocks at the time, and obviously, the incoming packets 
from the OSTC are coming in 20 byte packets, so we run out of memory a 
some random point, depending when the libdc actually consumes the input 
buffer.


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

Re: QML UI theming

[Joakim Bygdell]

On 18 July 2017 at 15:39, Dirk Hohndel  wrote:

>
> > On Jul 18, 2017, at 2:16 AM, Davide DB  wrote:
> >
> > On 17 July 2017 at 22:14, Davide DB  wrote:
> >>
> >> My last try: we could just color dive number of those dives with five
> stars ;)
> >>
> >> davide@mobile
> >>
> >
> > While working with the latest APK I realized that the preference page
> > is a bit messed up.
> > There is a small offset on the panel and all strings are way too large
> > even in English. (see attachment)
>
> Hmm, this used to be wrapped and laid our correctly. Arg.
>
> > BTW I see that through all the app we used the common desktop
> > paradigma: "once I modify something I have to explicitly save it".
> > Hence we have the ubiquitous floppy disk button which covers part of the
> screen.
> > Except few specific cases (i.e. save to cloud) in all Android/IOS apps
> > I used, the save action is implicit while changing some parameter.
>
> We actually modify the theme immediately... I'm ok with modifying
> all the settings immediately. But then we need a different paradigm
> that gets us out of there. I guess the back button on Android and
> throwing the phone against the wall until it breaks under iOS.
>

Or you could just tap the "Divelist" at the top statusbar.


> /D
>
>


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

Re: QML UI theming

[Davide DB]

On 18 July 2017 at 15:39, Dirk Hohndel  wrote:
> We actually modify the theme immediately... I'm ok with modifying
> all the settings immediately. But then we need a different paradigm
> that gets us out of there. I guess the back button on Android and
> throwing the phone against the wall until it breaks under iOS.

You know nothing [GOT cit.]

You still have to see what I'm sketching now...


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

Re: QML UI theming

[Dirk Hohndel]

> On Jul 18, 2017, at 2:16 AM, Davide DB  wrote:
> 
> On 17 July 2017 at 22:14, Davide DB  wrote:
>> 
>> My last try: we could just color dive number of those dives with five stars 
>> ;)
>> 
>> davide@mobile
>> 
> 
> While working with the latest APK I realized that the preference page
> is a bit messed up.
> There is a small offset on the panel and all strings are way too large
> even in English. (see attachment)

Hmm, this used to be wrapped and laid our correctly. Arg.

> BTW I see that through all the app we used the common desktop
> paradigma: "once I modify something I have to explicitly save it".
> Hence we have the ubiquitous floppy disk button which covers part of the 
> screen.
> Except few specific cases (i.e. save to cloud) in all Android/IOS apps
> I used, the save action is implicit while changing some parameter.

We actually modify the theme immediately... I'm ok with modifying
all the settings immediately. But then we need a different paradigm
that gets us out of there. I guess the back button on Android and
throwing the phone against the wall until it breaks under iOS.

/D

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

Re: BLE on iOS

[Dirk Hohndel]

Hi Alex, Timur,

> On Jul 18, 2017, at 4:09 AM, Alex Blasche  wrote:
>> Nor sure if you are the right person for this on iOS - but if not, maybe you 
>> can
>> point me to the right person.
> 
> Timur (in cc) is the Apple master for QtBluetooth.

Excellent. So we can bug him for both iOS and Mac? :-)

>> When compiling Subsurface-mobile for iOS with BT_SUPPORT enabled, we don't
>> appear to get a valid QBluetoothLocalDevice at all. Asking for isValid() 
>> returns
>> false, asking for allDevices() returns an empty list.
>> I tried powerOn() but as expected that doesn't work, either.
> 
> QBluetoothLocalDevice is not possible on iOS. Apple does not expose this 
> information to app developers. The classes implementation is a dummy only. 
> The same is true for QBluetoothServer, QBluetoothSocket, 
> QBluetoothServiceDiscoveryAgent. Only the straight path to 
> QLowEnergyController (BTLE use cases) are supported. That means that only the 
> following class chain works:
> 
> QBluetoothDeviceDiscoveryAgent -> QBluetoothDeviceInfo -> 
> QLowEnergyController 

I don't want to sound like a downer... but I must have missed that explanation 
in the documentation. It would be kinda neat if the classes had a little 
warning that said "this doesn't work on iOS - implementation is a dummy". 
Looking at http://doc.qt.io/qt-5/qbluetoothlocaldevice.html I can't find any 
indication that I wouldn't be able to start with this...

Let's start a new #ifdef'ed path with the class chain you suggest.

> Also note, that iOS does not expose Bluetooth addresses. The platform 
> generates uuid's as id's for devices.

That's one of the things that puzzle me. It says the same about macOS in the 
documentation, yet we do get Bluetooth addresses on macOS - just not 100% 
reliably.

Anyway, I'll worry about macOS next, right now I'd love to see some sign of 
life on iOS...

Thanks for the help - I can virtually assure you that I'll be back with more 
questions. I assume that the documentation is maintained in git somewhere as 
well. As I work through this, should I try to propose changes to the docs? 
Where would I start to create pull requests for that?

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

RE: BLE on iOS

[Alex Blasche]

Hi Dirk,

> -Original Message-
> From: Dirk Hohndel [mailto:d...@hohndel.org]

> Nor sure if you are the right person for this on iOS - but if not, maybe you 
> can
> point me to the right person.

Timur (in cc) is the Apple master for QtBluetooth.

> When compiling Subsurface-mobile for iOS with BT_SUPPORT enabled, we don't
> appear to get a valid QBluetoothLocalDevice at all. Asking for isValid() 
> returns
> false, asking for allDevices() returns an empty list.
> I tried powerOn() but as expected that doesn't work, either.

QBluetoothLocalDevice is not possible on iOS. Apple does not expose this 
information to app developers. The classes implementation is a dummy only. The 
same is true for QBluetoothServer, QBluetoothSocket, 
QBluetoothServiceDiscoveryAgent. Only the straight path to QLowEnergyController 
(BTLE use cases) are supported. That means that only the following class chain 
works:

QBluetoothDeviceDiscoveryAgent -> QBluetoothDeviceInfo -> QLowEnergyController 

Also note, that iOS does not expose Bluetooth addresses. The platform generates 
uuid's as id's for devices.

> While this is all about foreground activity, I even entered the Info.plist 
> key for
> bluetooth-central.
> 
> So right now I am stuck before I even get to do anything - I cannot see the 
> BLE
> device.
> 
> (and yes, of course, Bluetooth is turned on in the settings of the iPad I was
> testing this with)

The only way to deal with those eventualities is to check the various errors in 
QBDeviceDiscoveryAgent and QLEController. 

--
Alex

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

RE: OSTC over BLE experiences and questions

[Alex Blasche]

> -Original Message-
> From: Jan Mulder [mailto:jlmul...@xs4all.nl]
> Sent: Tuesday, 18 July 2017 10:04
> To: Alex Blasche ; Dirk Hohndel 
> Cc: Subsurface Mailing List 
> Subject: Re: OSTC over BLE experiences and questions
> 
> On 14-07-17 08:34, Alex Blasche wrote:
> >
> >>> The immediate problem that I believe I can see is that the state
> >>> machine has a missing end transition on my side. The last descriptor
> >>> read of the service discovery is a failure and therefore the usual
> >>> Android callbacks which finish the discovery do not kick in. I have
> >>> to add an exit conditions which unfortunately means that you'll need
> >>> a custom patch for QtBluetoothLE.java. I am stuck in workshop today and
> tomorrow. I'll try to squeeze it somewhere in between.
> >
> > Ok, here is the patch: https://codereview.qt-project.org/#/c/200076/
> >
> > I was not able to test this due to lack of being able to setup a test 
> > server that
> has exactly this behavior. Hopefully you can verify for me that this finished 
> the
> service discovery. If it is successful you should see the following logging 
> output:
> >
> > W QtBluetoothGatt: Finished current discovery for service handle 
> 
> Ok, I compiled Qt 5.9.1 (using your configure spec) including the patch
> (200079) above and tested the transfer. The finished current discovery message
> is shown in the logcat. So, this patch LGTM.

Thank you very much for the feedback. Consider this patch part of 5.9.2

Please let me know if you run into more problems.
 
> > In addition there is one more patch which you may need if you encounter
> Dirk's problem with MTU handling:
> >
> > https://codereview.qt-project.org/#/c/199117/
> 
> Did not try this (yet). It does not seem related to my interface process.

Probably not needed for your device. It seems to honour the default MTU value.

--
Alex


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

BLE on iOS

[Dirk Hohndel]

Hi Alex,

Nor sure if you are the right person for this on iOS - but if not, maybe you 
can point me to the right person.

When compiling Subsurface-mobile for iOS with BT_SUPPORT enabled, we don't 
appear to get a valid QBluetoothLocalDevice at all. Asking for isValid() 
returns false, asking for allDevices() returns an empty list.
I tried powerOn() but as expected that doesn't work, either.

While this is all about foreground activity, I even entered the Info.plist key 
for bluetooth-central.

So right now I am stuck before I even get to do anything - I cannot see the BLE 
device.

(and yes, of course, Bluetooth is turned on in the settings of the iPad I was 
testing this with)

Any ideas?

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