Re: Overthinking on Subsurface mobile app UX

[Willem Ferguson]

On 23/06/2017 17:49, Dirk Hohndel wrote:

A new APK is up that adds two neat features

a) Android title bar / navigation bar color now matches our title bar color 
(and changes if you change the color theme)
b) Action button is now colored with our secondary color

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.267-arm.apk

Comments welcome :-)

/D
___
This is just a concept of an idea to indicate a date with each dive 
trip. See attached image. I think only the month and year are really 
important within this context. I was thinking of how to include the date 
and take up as little space as possible in the trip header, leaving 
maximal space for the text. This is also a concept without taking into 
account what may be do-able within QML. The probability is quite large 
that it is not do-able.


1) Is this an aesthetically acceptable way of approaching showing the 
date for each dive trip?
2) The date takes up 2 lines. Look at the top header of the three with a 
date. What to do in the case of a dive trip that fits on one line?


Kind regards,
willem



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

Re: Overthinking on Subsurface mobile app UX

[Benjamin]

Completely off topic, but the highlighted trip is something which really
inspires jealousy... :)

Benjamin

On Sat, 24 Jun 2017, 13:36 Willem Ferguson, 
wrote:

> On 23/06/2017 17:49, Dirk Hohndel wrote:
> > A new APK is up that adds two neat features
> >
> > a) Android title bar / navigation bar color now matches our title bar
> color (and changes if you change the color theme)
> > b) Action button is now colored with our secondary color
> >
> >
> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.267-arm.apk
> >
> > Comments welcome :-)
> >
> > /D
> > ___
> This is just a concept of an idea to indicate a date with each dive
> trip. See attached image. I think only the month and year are really
> important within this context. I was thinking of how to include the date
> and take up as little space as possible in the trip header, leaving
> maximal space for the text. This is also a concept without taking into
> account what may be do-able within QML. The probability is quite large
> that it is not do-able.
>
> 1) Is this an aesthetically acceptable way of approaching showing the
> date for each dive trip?
> 2) The date takes up 2 lines. Look at the top header of the three with a
> date. What to do in the case of a dive trip that fits on one line?
>
> Kind regards,
> willem
>
>
>
> ___
> 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

QtWebEngine and Mingw

[Lubomir I. Ivanov]

i've just updated my Qt to 5.9.0 on Windows with the Mingw 5.3.0 toolchain.

but i'm facing a bug where the WebEngine libaries and cmake files are missing:
https://bugreports.qt.io/browse/QTBUG-61394

after reading more into it, it seems it might not be an actual bug...:
https://bugreports.qt.io/browse/QTBUG-42725

people in the above thread say that QWebEngine relies on the Chromium
engine as a backend and Chromium cannot be build using Mingw on
Windows - MSVC or clang needs to be used, so to me this means that if
you want to deploy a Qt based app on Windows that uses QWebEngine it
has to be built using MSVC or clang.

if so, that's a bummer.

the thread is old, but there are recent comments bellow that suggest
to use a fork of QtWebKit, which is what we are using now - is that
correct?

i will investigate further into this, but i'm going to assume that
switching to clang is a possibility (if QtWebEngine supports that - i
don't exactly understand the details here), while MSVC is out of the
question?

CCing Dirk and Thiago for insight.

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

Re: Overthinking on Subsurface mobile app UX

[James Cialdea]

If the trips were collapsible, I would want to see the date as you propose.
Since they're not, it seems redundant to the dive row, but a fine addition.


On Jun 24, 2017 6:37 AM, "Willem Ferguson" 
wrote:

On 23/06/2017 17:49, Dirk Hohndel wrote:

> A new APK is up that adds two neat features
>
> a) Android title bar / navigation bar color now matches our title bar
> color (and changes if you change the color theme)
> b) Action button is now colored with our secondary color
>
> http://subsurface-divelog.org/downloads/test/Subsurface-mobi
> le-4.6.4.267-arm.apk
>
> Comments welcome :-)
>
> /D
> ___
>
This is just a concept of an idea to indicate a date with each dive trip.
See attached image. I think only the month and year are really important
within this context. I was thinking of how to include the date and take up
as little space as possible in the trip header, leaving maximal space for
the text. This is also a concept without taking into account what may be
do-able within QML. The probability is quite large that it is not do-able.

1) Is this an aesthetically acceptable way of approaching showing the date
for each dive trip?
2) The date takes up 2 lines. Look at the top header of the three with a
date. What to do in the case of a dive trip that fits on one line?

Kind regards,
willem




___
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: Overthinking on Subsurface mobile app UX

[Dirk Hohndel]

I'm not sure if you mean 65m/1:51 or 2.2m/1:13 ?
:-)

⁣--
>From my phone​


 Original Message 
From: Benjamin 
Sent: Sat Jun 24 03:52:28 PDT 2017
To: willemfergu...@zoology.up.ac.za, Dirk Hohndel , Davide DB 

Cc: subsurface@subsurface-divelog.org
Subject: Re: Overthinking on Subsurface mobile app UX

Completely off topic, but the highlighted trip is something which really
inspires jealousy... :)

Benjamin

On Sat, 24 Jun 2017, 13:36 Willem Ferguson, 
wrote:

> On 23/06/2017 17:49, Dirk Hohndel wrote:
> > A new APK is up that adds two neat features
> >
> > a) Android title bar / navigation bar color now matches our title bar
> color (and changes if you change the color theme)
> > b) Action button is now colored with our secondary color
> >
> >
> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.267-arm.apk
> >
> > Comments welcome :-)
> >
> > /D
> > ___
> This is just a concept of an idea to indicate a date with each dive
> trip. See attached image. I think only the month and year are really
> important within this context. I was thinking of how to include the date
> and take up as little space as possible in the trip header, leaving
> maximal space for the text. This is also a concept without taking into
> account what may be do-able within QML. The probability is quite large
> that it is not do-able.
>
> 1) Is this an aesthetically acceptable way of approaching showing the
> date for each dive trip?
> 2) The date takes up 2 lines. Look at the top header of the three with a
> date. What to do in the case of a dive trip that fits on one line?
>
> Kind regards,
> willem
>
>
>
> ___
> 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: QtWebEngine and Mingw

[Dirk Hohndel]

> On Jun 24, 2017, at 6:59 AM, Lubomir I. Ivanov  wrote:
> 
> i've just updated my Qt to 5.9.0 on Windows with the Mingw 5.3.0 toolchain.
> 
> but i'm facing a bug where the WebEngine libaries and cmake files are missing:
> https://bugreports.qt.io/browse/QTBUG-61394
> 
> after reading more into it, it seems it might not be an actual bug...:
> https://bugreports.qt.io/browse/QTBUG-42725
> 
> people in the above thread say that QWebEngine relies on the Chromium
> engine as a backend and Chromium cannot be build using Mingw on
> Windows - MSVC or clang needs to be used, so to me this means that if
> you want to deploy a Qt based app on Windows that uses QWebEngine it
> has to be built using MSVC or clang.

Hmm, that's odd. Have you looked at what MXE does about that? Because
that's what I use to cross build everything. I haven't upgraded that to Qt 5.9,
though (and I always need to compile that from source anyway)

> if so, that's a bummer.

I would agree. Changing my build environment to clang would not make me
happy.

> the thread is old, but there are recent comments bellow that suggest
> to use a fork of QtWebKit, which is what we are using now - is that
> correct?

We use the "current" (but unmaintained) QtWebKit that is part of the
sources. Once 5.9.1 is out (which should happen within a week) I will
build that from source on MXE.

> i will investigate further into this, but i'm going to assume that
> switching to clang is a possibility (if QtWebEngine supports that - i
> don't exactly understand the details here), while MSVC is out of the
> question?

MSVC is out of the question. clang is possible, but not something I
look forward to - unless MXE has a clang branch which I haven't seen
(and yes, I did look).

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

Re: QtWebEngine and Mingw

[Lubomir I. Ivanov]

On 24 June 2017 at 18:15, Dirk Hohndel  wrote:
>
>> On Jun 24, 2017, at 6:59 AM, Lubomir I. Ivanov  wrote:
>>
>> i've just updated my Qt to 5.9.0 on Windows with the Mingw 5.3.0 toolchain.
>>
>> but i'm facing a bug where the WebEngine libaries and cmake files are 
>> missing:
>> https://bugreports.qt.io/browse/QTBUG-61394
>>
>> after reading more into it, it seems it might not be an actual bug...:
>> https://bugreports.qt.io/browse/QTBUG-42725
>>
>> people in the above thread say that QWebEngine relies on the Chromium
>> engine as a backend and Chromium cannot be build using Mingw on
>> Windows - MSVC or clang needs to be used, so to me this means that if
>> you want to deploy a Qt based app on Windows that uses QWebEngine it
>> has to be built using MSVC or clang.
>
> Hmm, that's odd. Have you looked at what MXE does about that? Because
> that's what I use to cross build everything. I haven't upgraded that to Qt 
> 5.9,
> though (and I always need to compile that from source anyway)
>

found this error report about MXE and QtWebEngine:
https://github.com/mxe/mxe/issues/1509

"Qt WebEngine on Windows requires MSVC 2013 or MSVC 2015.
QtWebEngine will not be built."

>> if so, that's a bummer.
>
> I would agree. Changing my build environment to clang would not make me
> happy.
>
>> the thread is old, but there are recent comments bellow that suggest
>> to use a fork of QtWebKit, which is what we are using now - is that
>> correct?
>
> We use the "current" (but unmaintained) QtWebKit that is part of the
> sources. Once 5.9.1 is out (which should happen within a week) I will
> build that from source on MXE.

i've downloaded the qtwebkit-5.212.0_alpha2-qt59-mingw530-x86.zip
from here:
https://github.com/annulen/webkit/releases

>
>> i will investigate further into this, but i'm going to assume that
>> switching to clang is a possibility (if QtWebEngine supports that - i
>> don't exactly understand the details here), while MSVC is out of the
>> question?
>
> MSVC is out of the question. clang is possible, but not something I
> look forward to - unless MXE has a clang branch which I haven't seen
> (and yes, I did look).
>

maybe if everything is mingw based and only QtWebEngine is build with
clang and that library is compatible with the rest of the Qt's Mingw
binaries it will work.
but to my understanding the C++ ABI is not compatible between clang
and mingw, which means the above is not possible without
"modifications".

also Qt don't support official llvm or clang binaries on windows and
it's either mingw or MSVC unless one attempts to build the whole Qt
himself with a different compiler.

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

Re: QtWebEngine and Mingw

[Lubomir I. Ivanov]

On 24 June 2017 at 18:33, Lubomir I. Ivanov  wrote:
>
> maybe if everything is mingw based and only QtWebEngine is build with
> clang and that library is compatible with the rest of the Qt's Mingw
> binaries it will work.
> but to my understanding the C++ ABI is not compatible between clang
> and mingw, which means the above is not possible without
> "modifications".
>

to summarize:
this leaves in a bit of a stalemate and unless Thiago has some sort of
an idea, we should just stick with WebKit for as long as possible, or
until:
1) clang WebEngine binaries can be used from mingw binaries
2) if we can build the whole Subsurface project using clang for
Windows and WebEngine is also built using clang

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

Re: Overthinking on Subsurface mobile app UX

[Benjamin]

One day I'll get to see a coelacanth in real life. And not just one in a
museum. :)

On Sat, 24 Jun 2017, 17:38 Dirk Hohndel,  wrote:

> I'm not sure if you mean 65m/1:51 or 2.2m/1:13 ?
> :-)
>
> --
> From my phone
> --
> *From:* Benjamin
> *Sent:* Sat Jun 24 03:52:28 PDT 2017
> *To:* willemfergu...@zoology.up.ac.za, Dirk Hohndel , Davide DB
> *Cc:* subsurface@subsurface-divelog.org
>
> *Subject:* Re: Overthinking on Subsurface mobile app UX
>
> Completely off topic, but the highlighted trip is something which really
> inspires jealousy... :)
>
> Benjamin
>
> On Sat, 24 Jun 2017, 13:36 Willem Ferguson, <
> willemfergu...@zoology.up.ac.za> wrote:
>
>> On 23/06/2017 17:49, Dirk Hohndel wrote:
>> > A new APK is up that adds two neat features
>> >
>> > a) Android title bar / navigation bar color now matches our title bar
>> color (and changes if you change the color theme)
>> > b) Action button is now colored with our secondary color
>> >
>> >
>> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.267-arm.apk
>> >
>> > Comments welcome :-)
>> >
>> > /D
>> > ___
>> This is just a concept of an idea to indicate a date with each dive
>> trip. See attached image. I think only the month and year are really
>> important within this context. I was thinking of how to include the date
>> and take up as little space as possible in the trip header, leaving
>> maximal space for the text. This is also a concept without taking into
>> account what may be do-able within QML. The probability is quite large
>> that it is not do-able.
>>
>> 1) Is this an aesthetically acceptable way of approaching showing the
>> date for each dive trip?
>> 2) The date takes up 2 lines. Look at the top header of the three with a
>> date. What to do in the case of a dive trip that fits on one line?
>>
>> Kind regards,
>> willem
>>
>>
>>
>> ___
>> 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: QtWebEngine and Mingw

[Thiago Macieira]

On sábado, 24 de junho de 2017 08:40:49 PDT Lubomir I. Ivanov wrote:
> to summarize:
> this leaves in a bit of a stalemate and unless Thiago has some sort of
> an idea,

Sorry, I don't have an idea.

> we should just stick with WebKit for as long as possible, or
> until:
> 1) clang WebEngine binaries can be used from mingw binaries

I don't think they can. The one being discussed here is the target "x86_64-
windows" which is compatible with MSVC (a.k.a clang-cl), not "x86_64-mingw" 
which is compatible with MinGW.

> 2) if we can build the whole Subsurface project using clang for
> Windows and WebEngine is also built using clang

Which is the same as switching to MSVC and build on Windows. My experience 
with clang-cl isn't very good, but at least you an mix it with MSVC and use 
2015 or 2017 where Clang-cl is still lacking.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Overthinking on Subsurface mobile app UX

[Davide DB]

To dream of it on the couch I can link you the French documentary about
Coelacanth ;)

davide@mobile

On Jun 24, 2017 5:49 PM, "Benjamin"  wrote:

One day I'll get to see a coelacanth in real life. And not just one in a
museum. :)

On Sat, 24 Jun 2017, 17:38 Dirk Hohndel,  wrote:

> I'm not sure if you mean 65m/1:51 or 2.2m/1:13 ?
> :-)
>
> --
> From my phone
> --
> *From:* Benjamin
> *Sent:* Sat Jun 24 03:52:28 PDT 2017
> *To:* willemfergu...@zoology.up.ac.za, Dirk Hohndel , Davide DB
> *Cc:* subsurface@subsurface-divelog.org
>
> *Subject:* Re: Overthinking on Subsurface mobile app UX
>
> Completely off topic, but the highlighted trip is something which really
> inspires jealousy... :)
>
> Benjamin
>
> On Sat, 24 Jun 2017, 13:36 Willem Ferguson, <
> willemfergu...@zoology.up.ac.za> wrote:
>
>> On 23/06/2017 17:49, Dirk Hohndel wrote:
>> > A new APK is up that adds two neat features
>> >
>> > a) Android title bar / navigation bar color now matches our title bar
>> color (and changes if you change the color theme)
>> > b) Action button is now colored with our secondary color
>> >
>> > http://subsurface-divelog.org/downloads/test/Subsurface-
>> mobile-4.6.4.267-arm.apk
>> >
>> > Comments welcome :-)
>> >
>> > /D
>> > ___
>> This is just a concept of an idea to indicate a date with each dive
>> trip. See attached image. I think only the month and year are really
>> important within this context. I was thinking of how to include the date
>> and take up as little space as possible in the trip header, leaving
>> maximal space for the text. This is also a concept without taking into
>> account what may be do-able within QML. The probability is quite large
>> that it is not do-able.
>>
>> 1) Is this an aesthetically acceptable way of approaching showing the
>> date for each dive trip?
>> 2) The date takes up 2 lines. Look at the top header of the three with a
>> date. What to do in the case of a dive trip that fits on one line?
>>
>> Kind regards,
>> willem
>>
>>
>>
>> ___
>> 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: Overthinking on Subsurface mobile app UX

[Davide DB]

On Jun 24, 2017 12:36 PM, "Willem  wrote:


>
> This is just a concept of an idea to indicate a date with each dive trip.
See attached image. I think only the month and year are really important
within this context. I was thinking of how to include the date and take up
as little space as possible in the trip header, leaving maximal space for
the text. This is also a concept without taking into account what may be
do-able within QML. The probability is quite large that it is not do-able.

1) Is this an aesthetically acceptable way of approaching showing the date
for each dive trip?
2) The date takes up 2 lines. Look at the top header of the three with a
date. What to do in the case of a dive trip that fits on one line?

Kind regards,
willem


IMHO.
We could just flow the rex on two rows and then add date in short form with
a light font.
In this way the space you used for the date would be used for a fancy
icon/image which pressed expand/collapse the trip.

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

Dive download crash - Qt model issues

[Linus Torvalds]

So because I'm testing my BLE code (yes, I have working downloads on
the Suunto EON Steel over BLE - no, it's not ready to be merged yet,
and other dive computers won't automatically work), I've been doing
odd things when downloading.

And I hit an issue that seems to be about the Qt models, not the
low-level downloading code itself.

It seems reproducible to me (and happens even without the BLE code, I
just checked), so maybe somebody else could take a look. Somebody who
knows our Qt models (Tomaz?)

The way to cause the crash is:

 - have all existing dives downloaded (but want to download again due
to testing downloading)

 - download dives, forgetting to check the "Force all dives" button

 - "Arghh, nothing downloaded"

 - Check the "Force all dives" button and then press "Retry download"

and when I do that, I get

  ASSERT: "last >= first" in file itemmodels/qabstractitemmodel.cpp, line 2743
  Aborted (core dumped)

Now, it may be that (once more) this is because I run my self-compiled
Qt, and apparently it ends up adding more sanity checks and asserts
when built in developer mode. So maybe it's not so reproducible for
others as it is for me.

The relevant gdb back-trace seems to be:

DownloadFromDCWidget::on_downloadCancelRetryButton_clicked() ->
  DiveImportedModel::clearTable() ->
QAbstractItemModel::beginRemoveRows()

and it's that beginRemoveRows() function (inside Qt) that fails the
assert. Not very informative to me, but maybe it makes somebody who
knows the model code go "Ahh, yes.."

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

Re: Dive download crash - Qt model issues

[Dirk Hohndel]

> On Jun 24, 2017, at 10:16 AM, Linus Torvalds  
> wrote:
> 
> So because I'm testing my BLE code (yes, I have working downloads on
> the Suunto EON Steel over BLE - no, it's not ready to be merged yet,
> and other dive computers won't automatically work), I've been doing
> odd things when downloading.
> 
> And I hit an issue that seems to be about the Qt models, not the
> low-level downloading code itself.
> 
> It seems reproducible to me (and happens even without the BLE code, I
> just checked), so maybe somebody else could take a look. Somebody who
> knows our Qt models (Tomaz?)
> 
> The way to cause the crash is:
> 
> - have all existing dives downloaded (but want to download again due
> to testing downloading)
> 
> - download dives, forgetting to check the "Force all dives" button
> 
> - "Arghh, nothing downloaded"
> 
> - Check the "Force all dives" button and then press "Retry download"
> 
> and when I do that, I get
> 
>  ASSERT: "last >= first" in file itemmodels/qabstractitemmodel.cpp, line 2743
>  Aborted (core dumped)

This is one of the ASSERTs in Qt that are compiled out in production code,
so I'm pretty sure those with my binaries or who are compiling from source
using standard Qt libraries won't see it.

> Now, it may be that (once more) this is because I run my self-compiled
> Qt, and apparently it ends up adding more sanity checks and asserts
> when built in developer mode. So maybe it's not so reproducible for
> others as it is for me.
> 
> The relevant gdb back-trace seems to be:
> 
> DownloadFromDCWidget::on_downloadCancelRetryButton_clicked() ->
>  DiveImportedModel::clearTable() ->
>QAbstractItemModel::beginRemoveRows()

That should be easy to fix. In clearTable() do as the first line

if (lastIndex < firstIndex)
return;

and you shouldn't see this crash anymore.

Tomaz, why are we setting lastIndex to -1 instead of 0 (which would seem
more reasonable to me and would avoid this assert)?

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

Re: Overthinking on Subsurface mobile app UX

[Dirk Hohndel]

> On Jun 24, 2017, at 9:11 AM, Davide DB  wrote:
> 
> 
> 
> On Jun 24, 2017 12:36 PM, "Willem  > wrote:
> 
> 
> This is just a concept of an idea to indicate a date with each dive trip. See 
> attached image. I think only the month and year are really important within 
> this context. I was thinking of how to include the date and take up as little 
> space as possible in the trip header, leaving maximal space for the text. 
> This is also a concept without taking into account what may be do-able within 
> QML. The probability is quite large that it is not do-able.
> 
> 1) Is this an aesthetically acceptable way of approaching showing the date 
> for each dive trip?
> 2) The date takes up 2 lines. Look at the top header of the three with a 
> date. What to do in the case of a dive trip that fits on one line?
> 
> Kind regards,
> willem
> 
> IMHO.
> We could just flow the rex on two rows and then add date in short form with a 
> light font.
> In this way the space you used for the date would be used for a fancy 
> icon/image which pressed expand/collapse the trip.

So we already flow the trip location to multiple rows if it gets to long. But 
having the date simply flow seems weird to me - I want the date to be in a 
fixed spot so I can immediately see it.
I don't think that small icons / images in the trip title are really all that 
useful, so personally I like Willem's idea better.

/D

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

Re: Overthinking on Subsurface mobile app UX

[Linus Torvalds]

On Sat, Jun 24, 2017 at 10:25 AM, Dirk Hohndel  wrote:
>
> I don't think that small icons / images in the trip title are really all
> that useful, so personally I like Willem's idea better.

I liked Willem's mockup a lot.

Even without dive trip collapsing, having the month/year in fairly big
letters on the trip header would be nice for when you scan for a
particular trip, and Willem's approach looked good for that.

And if/when the collapsing happens, it will obviously be really important.

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

Re: Overthinking on Subsurface mobile app UX

[Benjamin]

I've seen a lot of the ones on Youtube. Halfway there with trimix training.
Now I also need to start slowly on the rebreather route and then I'll be
able to consider actually starting to work up to doing the dives. :)

On 24 June 2017 at 19:06, Davide DB  wrote:

> To dream of it on the couch I can link you the French documentary about
> Coelacanth ;)
>
> davide@mobile
>
> On Jun 24, 2017 5:49 PM, "Benjamin"  wrote:
>
> One day I'll get to see a coelacanth in real life. And not just one in a
> museum. :)
>
> On Sat, 24 Jun 2017, 17:38 Dirk Hohndel,  wrote:
>
>> I'm not sure if you mean 65m/1:51 or 2.2m/1:13 ?
>> :-)
>>
>> --
>> From my phone
>> --
>> *From:* Benjamin
>> *Sent:* Sat Jun 24 03:52:28 PDT 2017
>> *To:* willemfergu...@zoology.up.ac.za, Dirk Hohndel , Davide DB
>> *Cc:* subsurface@subsurface-divelog.org
>>
>> *Subject:* Re: Overthinking on Subsurface mobile app UX
>>
>> Completely off topic, but the highlighted trip is something which really
>> inspires jealousy... :)
>>
>> Benjamin
>>
>> On Sat, 24 Jun 2017, 13:36 Willem Ferguson, <
>> willemfergu...@zoology.up.ac.za> wrote:
>>
>>> On 23/06/2017 17:49, Dirk Hohndel wrote:
>>> > A new APK is up that adds two neat features
>>> >
>>> > a) Android title bar / navigation bar color now matches our title bar
>>> color (and changes if you change the color theme)
>>> > b) Action button is now colored with our secondary color
>>> >
>>> > http://subsurface-divelog.org/downloads/test/Subsurface-mobi
>>> le-4.6.4.267-arm.apk
>>> >
>>> > Comments welcome :-)
>>> >
>>> > /D
>>> > ___
>>> This is just a concept of an idea to indicate a date with each dive
>>> trip. See attached image. I think only the month and year are really
>>> important within this context. I was thinking of how to include the date
>>> and take up as little space as possible in the trip header, leaving
>>> maximal space for the text. This is also a concept without taking into
>>> account what may be do-able within QML. The probability is quite large
>>> that it is not do-able.
>>>
>>> 1) Is this an aesthetically acceptable way of approaching showing the
>>> date for each dive trip?
>>> 2) The date takes up 2 lines. Look at the top header of the three with a
>>> date. What to do in the case of a dive trip that fits on one line?
>>>
>>> Kind regards,
>>> willem
>>>
>>>
>>>
>>> ___
>>> 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: Dive download crash - Qt model issues

[Thiago Macieira]

On sábado, 24 de junho de 2017 10:16:06 PDT Linus Torvalds wrote:
> Now, it may be that (once more) this is because I run my self-compiled
> Qt, and apparently it ends up adding more sanity checks and asserts
> when built in developer mode.

Going off on a tangent here, but...

Qt has release mode, debug mode and the "-developer-mode" switch. Be careful 
not to confuse the latter two: developer mode is debug mode but enables a few 
extra things so Qt's own unit tests can run, like exporting some functions so 
they can be called from the tests. Another consequence is that it compiles 
with -Werror and compiles each header individually, so the build time 
increases and you're more likely to get build failures.

Unless you're developing Qt itself like me, you don't want that option. Debug 
mode is fine for debugging into Qt itself and enables Q_ASSERT.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Dive download crash - Qt model issues

[Dirk Hohndel]

> On Jun 24, 2017, at 10:54 AM, Thiago Macieira  wrote:
> 
> On sábado, 24 de junho de 2017 10:16:06 PDT Linus Torvalds wrote:
>> Now, it may be that (once more) this is because I run my self-compiled
>> Qt, and apparently it ends up adding more sanity checks and asserts
>> when built in developer mode.
> 
> Going off on a tangent here, but...
> 
> Qt has release mode, debug mode and the "-developer-mode" switch. Be careful 
> not to confuse the latter two: developer mode is debug mode but enables a few 
> extra things so Qt's own unit tests can run, like exporting some functions so 
> they can be called from the tests. Another consequence is that it compiles 
> with -Werror and compiles each header individually, so the build time 
> increases and you're more likely to get build failures.
> 
> Unless you're developing Qt itself like me, you don't want that option. Debug 
> mode is fine for debugging into Qt itself and enables Q_ASSERT.

Linus is working with Alex on fixing the broken BLE support in Qt. So in that
sense, I'm pretty sure he is "developing Qt itself".

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

Re: Dive download crash - Qt model issues

[Stefan Fuchs]

Hi All,

Am 24.06.2017 um 19:24 schrieb Dirk Hohndel:
>
> This is one of the ASSERTs in Qt that are compiled out in production code,
> so I'm pretty sure those with my binaries or who are compiling from source
> using standard Qt libraries won't see it.
>
>> Now, it may be that (once more) this is because I run my self-compiled
>> Qt, and apparently it ends up adding more sanity checks and asserts
>> when built in developer mode. So maybe it's not so reproducible for
>> others as it is for me.
>>
>> The relevant gdb back-trace seems to be:
>>
>> DownloadFromDCWidget::on_downloadCancelRetryButton_clicked() ->
>>  DiveImportedModel::clearTable() ->
>>QAbstractItemModel::beginRemoveRows()
> That should be easy to fix. In clearTable() do as the first line
>
> if (lastIndex < firstIndex)
>   return;
>
> and you shouldn't see this crash anymore.
Just as a side note: Dirk and I already fixed s.th. very similar in this
part of the code some time ago:
https://github.com/Subsurface-divelog/subsurface/commit/02e768a61beda2730efff1e84f5e5b7341418acf
https://github.com/Subsurface-divelog/subsurface/issues/332

Best regards
Stefan

-- 

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

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

Re: Dive download crash - Qt model issues

[Linus Torvalds]

On Sat, Jun 24, 2017 at 10:54 AM, Thiago Macieira  wrote:
>
> Qt has release mode, debug mode and the "-developer-mode" switch. Be careful
> not to confuse the latter two: developer mode is debug mode but enables a few
> extra things so Qt's own unit tests can run, like exporting some functions so
> they can be called from the tests. Another consequence is that it compiles
> with -Werror and compiles each header individually, so the build time
> increases and you're more likely to get build failures.
>
> Unless you're developing Qt itself like me, you don't want that option. Debug
> mode is fine for debugging into Qt itself and enables Q_ASSERT.

The problem is that I have to build my own Qt library for the
bluetooth debugging, but I do *not* want to install it over the system
binaries (or, in fact, install it at all).

The solution to that problem is "--developer-build".  That actually
does exactly the right thing from a "build one single app against the
special Qt tree that has a couple of experimental patches"
perspective.

However, that solution is somewhat annoying, exactly because of things
like "-Werror" (which trigger errors that are compiler version
dependent, and in particular triggers errors in things like QtWebKit
that most Qt people don't seem to test because they prefer the
currently broken alternatives).

Honestly, I'd probably prefer a non-debug developer mode, but the
extra debug printouts it also seems to cause were actually super
helpful for getting BLE going.

The extra Q_ASSERT's? Yeah, not so much.

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

Error: "Must construct a QApplication before a QWidget"

[Lubomir I. Ivanov]

i've updated to Qt 5.9.0 today and after building Subsurface on
Windows i'm getting a:

QWidget: Must construct a QApplication before a QWidget
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.

and the app terminates with:
"This application has requested the Runtime to terminate it in an unusual way."

the above error cannot be debugged properly most of the time (e.g. asserts).

https://stackoverflow.com/questions/23804238/debugging-qwidget-must-construct-a-qapplication-before-a-qwidget-invalid-par

according the comments in the thread we are probably creating a widget
in a header somewhere before the QApplication instance in created.

i'm trying to hunt what widget / header is causing that.

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

Re: Error: "Must construct a QApplication before a QWidget"

[Dirk Hohndel]

> On Jun 24, 2017, at 11:16 AM, Lubomir I. Ivanov  wrote:
> 
> i've updated to Qt 5.9.0 today and after building Subsurface on
> Windows i'm getting a:
> 
> QWidget: Must construct a QApplication before a QWidget
> Invalid parameter passed to C runtime function.
> Invalid parameter passed to C runtime function.
> 
> and the app terminates with:
> "This application has requested the Runtime to terminate it in an unusual 
> way."
> 
> the above error cannot be debugged properly most of the time (e.g. asserts).
> 
> https://stackoverflow.com/questions/23804238/debugging-qwidget-must-construct-a-qapplication-before-a-qwidget-invalid-par
> 
> according the comments in the thread we are probably creating a widget
> in a header somewhere before the QApplication instance in created.
> 
> i'm trying to hunt what widget / header is causing that.

Oh joy - this is one of the things I hate the most about C++
Random things happening in random order that make no sense to me.
I remember all the cases in which our translations aren't loaded when object 
are instantiated.

Thanks for hunting this down.

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

Re: [Mobile UI] Blue palette

[Dirk Hohndel]

On Thu, Jun 22, 2017 at 01:49:00PM +0200, Davide DB wrote:
> On 21 June 2017 at 22:13, Dirk Hohndel  wrote:
> >
> > Right now I use
> >
> > property color darkPrimaryColor: "#303F9f"
> > property color darkPrimaryTextColor: "#ECECEC"
> > property color primaryColor: "#3F51B5"
> > property color primaryTextColor: "#ECECEC"
> > property color lightPrimaryColor: "#C5CAE9"
> > property color lightPrimaryTextColor: "#212121"
> >
> 
> Hummm something strange is going on. Sorry I have to use a html email.
> 
> Regarding the original question on text colors.
> 
> My original palette was:
> 
> /* Palette generated by Material Palette -
> materialpalette.com/indigo/deep-orange */
> 
> .dark-primary-color{ background: #303F9F; }
> .default-primary-color { background: #3F51B5; }
> .light-primary-color   { background: #C5CAE9; }
> .text-primary-color{ color: #FF; }
> .accent-color  { background: #FF5722; }
> .primary-text-color{ color: #212121; }
> .secondary-text-color  { color: #757575; }
> .divider-color { border-color: #BDBDBD; }

Those names are at least as crazy and confusing as mine.
What's the difference between text-primary-color and primary-text-color?

> In our app we would have:
> 
> dive name in item list text (primary-text-color): #212121
> dive data in item list text: (secondary-text-color) #757575

That is weird. So two different colors for the the two lines for a dive?
And the contrast of that secondary text color against the background color
of #eff0f1 is going to be miserable.

> Trip bar background: (light-primary-color) #C5CAE9
> Trip bar text: (primary-text-color): #212121

That we already have

> Selected dive background: (default-primary-color) ##3F51B5
> Selected dive text: (text-primary-color) #FF

There we use a slightly darker gray, happy to switch to white for you.

> - white text is not our enemy when used on proper dark background.

Depends on your screen quality.

> - secondary text is grey which gives more evidence to the title hence in my
> scheme, dive data (date, depth...) in the item list are grey. Please just
> try once :-)

Sure. Coming up. I also think I may have found why it didn't render the
exact colors that we pick. The dive list had opacity of 0.8 which most
likely caused a background color bleeding through.

/D


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

Re: Dive download crash - Qt model issues

[Thiago Macieira]

On sábado, 24 de junho de 2017 11:05:25 PDT you wrote:
> The solution to that problem is "--developer-build".  That actually
> does exactly the right thing from a "build one single app against the
> special Qt tree that has a couple of experimental patches"
> perspective.

You can just do -prefix $PWD/qtbase if you're building from the top-level 
qt5.git.

You can also build only qtconnectivity on top of your existing libs and not 
install it. With LD_LIBRARY_PATH and QT_PLUGIN_PATH environment variables set, 
you should be able to run without installing too.

> Honestly, I'd probably prefer a non-debug developer mode, but the
> extra debug printouts it also seems to cause were actually super
> helpful for getting BLE going.

That should not have affected the debugging output... It seems to be a Fedora 
patch:
https://src.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtlogging.ini

You can override it by setting QT_LOGGING_RULES=*.debug=true

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: [Mobile UI] Blue palette

[Dirk Hohndel]

> On Jun 24, 2017, at 11:32 AM, Dirk Hohndel  wrote:
> 
> Sure. Coming up. I also think I may have found why it didn't render the
> exact colors that we pick. The dive list had opacity of 0.8 which most
> likely caused a background color bleeding through.

The new APK should give you exactly the colors you asked for:



Try it here:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.276-arm.apk

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

Re: [Mobile UI] Blue palette

[Dirk Hohndel]

> On Jun 24, 2017, at 12:18 PM, Dirk Hohndel  wrote:
> 
> 
>> On Jun 24, 2017, at 11:32 AM, Dirk Hohndel > > wrote:
>> 
>> Sure. Coming up. I also think I may have found why it didn't render the
>> exact colors that we pick. The dive list had opacity of 0.8 which most
>> likely caused a background color bleeding through.
> 
> The new APK should give you exactly the colors you asked for:
> 
> 
> 
> Try it here:
> 
> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.276-arm.apk
>  
> 
Or, you could try

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.277-arm.apk
 


which will give you something like this :-)



/D

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

Re: Error: "Must construct a QApplication before a QWidget"

[Lubomir I. Ivanov]

On 24 June 2017 at 21:29, Dirk Hohndel  wrote:
>
>> On Jun 24, 2017, at 11:16 AM, Lubomir I. Ivanov  wrote:
>>
>> i've updated to Qt 5.9.0 today and after building Subsurface on
>> Windows i'm getting a:
>>
>> QWidget: Must construct a QApplication before a QWidget
>> Invalid parameter passed to C runtime function.
>> Invalid parameter passed to C runtime function.
>>
>> and the app terminates with:
>> "This application has requested the Runtime to terminate it in an unusual 
>> way."
>>
>> the above error cannot be debugged properly most of the time (e.g. asserts).
>>
>> https://stackoverflow.com/questions/23804238/debugging-qwidget-must-construct-a-qapplication-before-a-qwidget-invalid-par
>>
>> according the comments in the thread we are probably creating a widget
>> in a header somewhere before the QApplication instance in created.
>>
>> i'm trying to hunt what widget / header is causing that.
>
> Oh joy - this is one of the things I hate the most about C++
> Random things happening in random order that make no sense to me.
> I remember all the cases in which our translations aren't loaded when object 
> are instantiated.
>
> Thanks for hunting this down.
>

looks like this error:
"QWidget: Must construct a QApplication before a QWidget"

is reported the first time a QWebView instance is created.

i've reported an error to the github project from where i've
downloaded these webkit binaries.
so it's probably just an error on my end.

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

Re: [Mobile UI] Blue palette

[Davide DB]

On Jun 24, 2017 10:17 PM, "Dirk Hohndel"  wrote:


On Jun 24, 2017, at 12:18 PM, Dirk Hohndel  wrote:


On Jun 24, 2017, at 11:32 AM, Dirk Hohndel  wrote:

Sure. Coming up. I also think I may have found why it didn't render the
exact colors that we pick. The dive list had opacity of 0.8 which most
likely caused a background color bleeding through.


The new APK should give you exactly the colors you asked for:



Try it here:

http://subsurface-divelog.org/downloads/test/Subsurface-
mobile-4.6.4.276-arm.apk


Or, you could try

http://subsurface-divelog.org/downloads/test/Subsurface-
mobile-4.6.4.277-arm.apk

which will give you something like this :-)


In the end Pink Theme rocks! :-)

Regarding the misterious color definitions I will dig the documentation to
see if there's a rationale behind them.

Regarding dive data colors once selected (date, depth etc...) you are
right. They sucks. Go directly for white or very light light gray.

Regarding plain/not selected dive data I find it perfect. It increases
difference from title and the whole dive list seems less crowdy.

You were right: 80% transparency was the culprit. Now everything matches
among screen rendering and color sets.

Let's see other comments.

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

Android / adb

[Dirk Hohndel]

On the off chance that someone here happens to know an answer...

I used to have problems on and off with my Pixel XL connecting to my
Linux VM in debug mode - but usually disconnecting and reconnecting
did the trip. Worst case I had to reboot one or the other. But today
nothing seems to help. I rebooted both, I turn USB debugging on the
phone off and on again. I cleared the authorized hosts. I switched
cables. Nothing works.

Linux sees the phone. But I don't get the request on the phone to
approve the host for debugging. And "adb devices" doesn't see the
phone, either.

Any suggestions?

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

Re: Android / adb

[Lubomir I. Ivanov]

On 25 June 2017 at 01:26, Dirk Hohndel  wrote:
>
> On the off chance that someone here happens to know an answer...
>
> I used to have problems on and off with my Pixel XL connecting to my
> Linux VM in debug mode - but usually disconnecting and reconnecting
> did the trip. Worst case I had to reboot one or the other. But today
> nothing seems to help. I rebooted both, I turn USB debugging on the
> phone off and on again. I cleared the authorized hosts. I switched
> cables. Nothing works.
>
> Linux sees the phone. But I don't get the request on the phone to
> approve the host for debugging. And "adb devices" doesn't see the
> phone, either.
>

happened to me a week ago on windows. after restarting the OS,
restarting the android device and disconnecting the cable multiple
times it just decided to work at some point.
i don't have an explanation.

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

Brave people - look at and test BLE downloads

[Linus Torvalds]

So I currently have the BLE GATT downloading working on both my Suunto
EON Steel and the Scubapro G2. This is to see if anybody else wants to
play with the code, but before looking at the code, a few faily big
caveats:

 (a) BLE is not fast. Just be warned. You *will* be happier with a USB
cable if you have that option.

 (b) divecomputers are odd, and not a lot of people seem to play with
them over bluetooth. At least Suunto seems to consider the BLE to be
mobile-only.  On desktop systems, bluetooth seems to be pretty hit and
miss outside of legacy mouse/keyboard/audio things. Odd BLE devices?
Yeah, bugs will happen.

 (c) I only work with Linux, and I don't do mobile. End result: right
now the code only works on Linux laptops and desktops with bluetooth.
A regular BT-4.0 USB dongle works fine for me on my desktop, and my
laptop has Intel wireless with BT that also works. So as long as it's
LE-capable (and not all BT dongles are), it probably works.

 (d) ...but I found several "features" due to (b), and you'll not only
need a fairly up-to-date Qt installation, you may need to literally
build your own due to Qt bugs (the EON Steel in particular is very
picky, and Qt/Bluez didn't connect to it without patches).

 (e) my BLE code is not pretty. It's scary. In fact, it can probably
be used to make small timid pets pee on the floor in fright. You have
been warned.

With those encouraging words, here's the scoop:

If using Qt, use at least 5.9.1, and if you want to play with the EON
Steel, make it work on some non-Bluez platform (which has so far never
been tested - Bluez is what the Linux desktop environments use), and
use the patch from here:

https://codereview.qt-project.org/#/c/198202/

You also need to make sure that you have "device privacy" enabled, at
least in order to pair with the EON Steel. It will not talk to you
unless you have a device identity key ("IRK"). With Bluez (ie Linux
desktop environment), this involves making sure that you have

Privacy = device

in your bluetooth config file (normally /etc/bluetooth/main.conf, and
normally it it set to "off").

Also, make sure that you have the current libdivecomputer
Subsurface-branch, which has the code for the EON Steel and the
Scubapro G2 to know the differences between a USB HID download and a
BLE GATT download.

And if y ou do all that, and if you apply the attached patch to the
current subsurface source base, and if you walk around three times
widdershins around your computer while you build it all, you *may*
just get working BLE GATT downloads.

I'll hopefully look at the Shearwater Perdix AI next. Since BLE is the
*only* way to download from that dive computer, it would be really
nice if I can make this work for that too. We'll see.

  Linus
From 43d17083dee67bcfac9e2d9f1a2a84011bc40113 Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Mon, 12 Jun 2017 19:47:50 -0700
Subject: [PATCH] Very early and likely quite broken BLE GATT code

This is some very early and hacky code to be able to access BLE-enabled
dive computers that use the GATT protocol to send packets back and forth
(which seems to be pretty much all of them: a vendor-specific GATT
service with a write characteristic and a notification characteristic
for reading).

For testing only.  But it does successfully let me download dives from
my EON Steel and my Scubapro G2.

NOTE! There are several very hacky pieces in here, including just
"knowing" that the write characteristic is the first one, and the
notification characteristic is second.  The code should actually check
the properties rather than have those kinds of hardcoded assumptions.

It also checks "vendor specific" by looking at the UUID string
representation, and knowing that the standard ones start with zero.
Crazily, there doesn't seem to be any normal way to test for this,
although I guess that maybe the uuid.minimumSize() function could be
used.

There are other nasty corners. Don't complain, send me patches.

Signed-off-by: Linus Torvalds 
---
 CMakeLists.txt |   9 ++
 core/CMakeLists.txt|   5 +
 core/qt-ble.cpp| 228 +
 core/qt-ble.h  |  38 
 core/qtserialbluetooth.cpp |  14 ++-
 scripts/build.sh   |   1 +
 6 files changed, 294 insertions(+), 1 deletion(-)
 create mode 100644 core/qt-ble.cpp
 create mode 100644 core/qt-ble.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3112c4b7..12bf1c4e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -216,10 +216,19 @@ if (BTSUPPORT AND "${Qt5Core_VERSION}" VERSION_LESS 5.4.0)
 	list(REMOVE_ITEM QT_LIBRARIES Qt5::Bluetooth)
 endif()
 
+#I can't test MacOS, and Windows Qt doesn't support BLE at all afaik
+if (BTSUPPORT AND CMAKE_SYSTEM_NAME STREQUAL "Linux")
+	set(BLESUPPORT ON)
+endif()
+
 if(BTSUPPORT)
 	add_definitions(-DBT_SUPPORT)
 endif()
 
+if(BLESUPPORT)
+	add_definitions(-DBLE_SUPPORT)
+endif()
+
 #set up the subsurface_link_librarie

Re: [Mobile UI] Blue palette

[Davide DB]

>From what I read those weird definitions are just an invention of that
palette generator. We have only a primary and an optional secondary color
and their light and dark variations.

I found this reply very informative:

https://ux.stackexchange.com/questions/89815/choosing-
colors-in-material-design


Basically text is always black #00 and you define opacity based on
background. There are fixed values for that.
Here Google explains the trick on text

https://material.io/guidelines/style/color.html#color-usability
Dark text on light backgrounds

The level of opacity used for text depends on whether your background is
dark or light. For dark text on light backgrounds, apply the following
opacity levels:

   - The most important text has an opacity of 87%.
   - Secondary text, which is lower in the visual hierarchy, has an opacity
   of 54%.
   - Text hints (such as text fields and labels) and disabled text have
   even lower visual prominence with an opacity of 38%.



Now, on our UI I see we no longer have distinction with the phone status
bar as before. Everything is of primary color while before we correctly
have it dark primary color.

I didn't noticed you changed also format of the dive name into the detail
page. Amazing. It has a small button [map it] too.

Is there any way to take advantage of the full screen width during the dive
edit?

PS
If it could be useful, next week I will play a bit with sidebar
organization and settings adding other idea on github.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Mobile UI] Blue palette

[Dirk Hohndel]

> On Jun 24, 2017, at 4:14 PM, Davide DB  wrote:
> 
> From what I read those weird definitions are just an invention of that 
> palette generator. We have only a primary and an optional secondary color and 
> their light and dark variations.
> 
> I found this reply very informative:
> 
> https://ux.stackexchange.com/questions/89815/choosing-colors-in-material-design
>  
> 
> 
> 
> Basically text is always black #00 and you define opacity based on 
> background. There are fixed values for that.
> Here Google explains the trick on text
> 
> https://material.io/guidelines/style/color.html#color-usability 
> 
> Dark text on light backgrounds
> 
> The level of opacity used for text depends on whether your background is dark 
> or light. For dark text on light backgrounds, apply the following opacity 
> levels:
> 
> The most important text has an opacity of 87%.
> Secondary text, which is lower in the visual hierarchy, has an opacity of 54%.
> Text hints (such as text fields and labels) and disabled text have even lower 
> visual prominence with an opacity of 38%.
> 
> 
> 

So that's not how we do it today - I'm actually happy with our approach to 
secondary color (I just need to fix it for the dark theme).
Unless you feel very strongly about this, I'd keep that as is for Blue and Pink

> Now, on our UI I see we no longer have distinction with the phone status bar 
> as before. Everything is of primary color while before we correctly have it 
> dark primary color.

I noticed that as I verified the colors. I bet this is just me confusing myself 
with my clever names again. I'll figure it out and get that back.

> I didn't noticed you changed also format of the dive name into the detail 
> page. Amazing. It has a small button [map it] too.

Yup.

> Is there any way to take advantage of the full screen width during the dive 
> edit?

That's the cool overlay page... I like it. You don't? Sure, we can change 
anything.

> If it could be useful, next week I will play a bit with sidebar organization 
> and settings adding other idea on github.

So far I think your work has been extremely useful. I often don't know how to 
implement things, but I'll be happy to try

Thanks

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

Mobile dive list development

[Willem Ferguson]

On 24/06/2017 22:17, Dirk Hohndel wrote:


On Jun 24, 2017, at 12:18 PM, Dirk Hohndel > wrote:



On Jun 24, 2017, at 11:32 AM, Dirk Hohndel > wrote:


Sure. Coming up. I also think I may have found why it didn't render the
exact colors that we pick. The dive list had opacity of 0.8 which most
likely caused a background color bleeding through.


The new APK should give you exactly the colors you asked for:



Try it here:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.276-arm.apk


Or, you could try

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.277-arm.apk


/D

This dive list presentation looks pretty good, I must say. I would give 
you 12 out of 10 for this.


Two smaller matters:

1) the presentation of multiple lines for dive titles goes a tiny bit 
off-screen on the right, losing 1 or 2 characters. I do not think the 
date box in the dive trip header has anything to do with that. This is 
the case both for the Samsung S3 and the S6 that I have access to. See 
attached image.


2) in the longer term, we would need the ability to edit the dive trip 
header information by using the mobile platform. But that would probably 
need a big rethink and open up a new can of worms, because it would 
eventually require the ability to create a new trip and add 
manually-created or downloaded dives to that trip.


3) in concert with the last point, the activation of the editing of a 
dive trip header needs to be pretty well thought through, especially if 
we later on perhaps want to use the tap of a dive trip title to expand 
or collapse the dives within that trip.


Kind regards,

willem


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

BLE download from EON Steel on Android

[Dirk Hohndel]

Linus,

I pushed out your changes to master.
With the latest Subsurface master and libdc Subsurface-branch I was able
to download dives from my EON Steel via BLE on Android.

Well, I was able to do it exactly once. I used the Nordic app to bond the
dive computer, then started the download from Subsurface. It worked
perfectly.

Since then I haven't been able to get the EON Steel to connect to my
phone... there's clearly some magic order of things that I happened to get
right that one time but don't quite know how to reproduce. But that said,
I had one successful attempt. And yes, you are right. This is SLOW.

Anyway, if others want to try, the APK with which this worked for me is
up:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.283-arm.apk

Testing, success and failure stories, and of course patches are welcome
:-)

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