Re: Subsurface for Android on F-Droid?

[Christof Arnosti via subsurface]

Hi,

Thanks for the positive feedback. I'm currently doing some research.

As far as I understand, it's currently not possible to run a 
user-defined docker container for builds for f-droid. Thus, we would 
have to recreate the build-environment to run in the containers that the 
f-droid build environment uses.


But first let's see if I get the build setup that subsurface uses:

 * The whole android build runs in a docker container as defined in
   
https://github.com/subsurface/subsurface/blob/master/scripts/docker/android-build-container/Dockerfile
 o This is basically installing QT (currently 5.15.1) and android
   SDK/NDK (currently platform 21)
 * then the build script is executed: packaging/android/qmake-build.sh

Since F-Droid (the repository) seems to be quite restrictive about how 
the software should be built (must be built on their own infrastructure 
using only source code - so no pre-built QT for example), another way 
could be to create a F-Droid repository for subsurface using the github 
build artifacts. This would not help with visibility (since it's not 
visible in F-Droid without installing the repository), but would enable 
automatic updates for F-Droid users.


If this would be the way forward, I think two repositories would make sense:

 * Nightly (automatically updated from the nightly github builds)
 * current / weekly / release (the releases that are currently on the
   webpage)

Since these APKs are the same that are also linked on the webpage, it 
should(tm) be possible to switch over from manually installed to F-Droid.


Here I have the question: How is the release-process for the "current" 
builds? I've seen that there are basically some APKs in a download 
folder, but I couldn't find any information if they are manually copied 
or if there is some automation going on.


Christof


On 24.05.24 04:04, Michael Keller via subsurface wrote:


Hi Christof.

On 24/05/24 12:10, Dirk Hohndel via subsurface wrote:
I definitely think that there would be interest. I have tried to go 
through the process a couple of years ago and couldn't figure it out.

But yeah, if you want to get a working build put together, I'd love that.

/D

On May 23, 2024, at 12:01, Christof Arnosti via subsurface 
 wrote:


Hi,

I currently only half-heartedly follow the mailing list, so please 
excuse if I missed some discussion.


As far as I understood, subsurface is not published on Play Store 
anymore due to the ever-changing requirements, which make it hard to 
actually publish it. This got me thinking: As far as I know all 
components needed to create a working subsurface APK are open 
source. This means that subsurface should manage to meet the 
Inclusion Policy of F-Droid 
(https://f-droid.org/en/docs/Inclusion_Policy/).


Thus I wanted to ask if there would generally be some interest to 
include Subsurface in the F-Droid store. If yes, I could try to take 
some time to check if I manage to get a working build of subsurface 
for F-Droid (no promises about finding the time and technical 
success tho!)




Yes, I think it's definitely a good idea.


From having a quick look at the F-Droid page, they seem to be 
requiring a fully automated build of the application on their 
infrastructure. To get this going, the piece de resistance will be the 
Qt build.


For Android, we are currently using a docker-image with a manually 
pre-built Qt installation 
(https://hub.docker.com/r/subsurface/android-build, which uses the Qt 
installation from 
https://hub.docker.com/r/subsurface/android-build-container). So 
unless F-Droid allows the use of docker images for their builds the Qt 
install on these images will have to be replicated in an automated way.



Cheers

  Michael Keller


___
subsurface mailing list --subsurface@subsurface-divelog.org
To unsubscribe send an email tosubsurface-le...@subsurface-divelog.org


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
subsurface mailing list -- subsurface@subsurface-divelog.org
To unsubscribe send an email to subsurface-le...@subsurface-divelog.org

Re: the new website is live

[Christof Arnosti via subsurface]

Hi,

Looking good!

Some small observations:

 * On the homepage, "Screenshot of rating, tags and other data fields"
   and "Screenshot of dive profile" are 404.
 * In the carousel, in the Cloud section, I think it would be a good
   idea to note that Cloud Storage is optional.
 * The link to the Sponsoring page in the menu is the only link which
   opens a new tab. I think it would be more consistent if the link
   itself opens in the same tab, but maybe the links to ko-fi and
   github open in a new page.

Best regards
Christof

On 04.02.24 00:47, Dirk Hohndel via subsurface wrote:

Thanks everyone for your help in getting this site started and debugged.
Thanks to Peter, Robert, and Salvador for providing complete translations to 
Dutch, German, and Spanish. I really appreciate your effort here. And so do our 
users in those respective languages.

Please keep testing the site - I tried to go through the various aspects of it, 
but I'm sure I overlooked something. I'll also announce this in the user forum 
in a moment, so I expect that to get us more eyeballs.


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


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

Re: Linux: Problems with Image files on external drive

[Christof Arnosti via subsurface]

Hi Willem,

For me this sounds like a permission problem when using snap.

According to 
https://askubuntu.com/questions/1034030/how-to-get-access-to-usb-storage-from-an-application-installed-as-snap, 
you can use "snap connect some-snap-name:removable-media" to allow an 
application installed by snap to use external media. Assuming that the 
subsurface snap is simply calles "subsurface", the command should be 
"snap connect subsurface:removable-media".


Best regards
Christof

Am 22.11.23 um 09:40 schrieb Willem Ferguson via subsurface:
My photographic images are on an external hard drive, labeled as 
'TOSHIBA EXT. I cannot access the images from within subsurface.This 
coincidental with moving to a fresh newly-intalled Ubuntu on a new 
clean machine.


I use Ubuntu 23.10

PROBLEM 1:
--
Permissions for the external drive as follows:
willemf@fergusn:/media$ ls -l willemf
total 4
drwxrwxrwx 1 willemf willemf 4096 Nov 19 16:45 'TOSHIBA EXT'

Obviously I work in the media directory located in the root directory 
and the first part of the path is /media/willemf/'TOSHIBA EXT'


The system location of one such image is:
willemf@fergusn:/media/willemf/TOSHIBA EXT/Fotos/Sodwana.2023 
Mei/darktable_exported

The relevant image in the above directory is:
$ ls White*
'Whitespotted butterflyfish Chaetodon kleinii.jpg'

The path and existence of the image is explicit.

The divelog reference of the above image is:



The reference in the divelog appears correct. Granted, the spaces in 
the reference cause complications but Linux can easily deal with that 
by using the ' ' notation.


Subsurface does not recognise any of these references in the dive log 
and consequently shows an "Image not found" icon in the media panel of 
Subsurface. I have no idea how to address this issue.


The above issue possibly relates to:

PROBLEM 2:
--

Cannot set image directory in Subsurface GUI

Screenshot from 2023-11-22 10-24-49.png

When I try and set the directory with images, it does not se anything 
within the media directory. Consequently it is impossible to import 
images into Subsurface. The above media directory is the one in the root.


Could this be an installation issue on my side? I installed the snap 
from the Subsurface website and did not build it myself.


One last gripe. My installation of Subsurface does not show a launch 
screen and directly goes to the full GUI with all the dive 
information. Thus I do not know which version of Subsurface I work 
with. But the snap  was installed 4 days ago. I cannot find the 
Subsurface log file.


Kind regards, Willem








Sent with Proton Mail  secure email.

___
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 5.0.7 has been released

[Christof Arnosti via subsurface]

Thanks, Dirk!

I just downloaded the AppImage built by github actions, and it works 
fine for me, including completely translated context menu for de_CH! 
(althouth I didn't test anything beside opening the context menu) :-)


I had a short look in the code, and added a small comment to the PR 
regarding Portuguese. Since pt_PT is complete I think the fallback 
should be pt_PT instead of pt_BR.


I did set my language to pt_PT and pt_BR to test this, and it seems in 
pt_BR about the same strings in the context menu are missing 
(pluralisation).



One thing I noticed: When I set the language to pt_*, I get the 
following message when I start subsurface:


$ ./Subsurface.AppImage
can't find Qt base localization for locale "pt-BR" searching in 
"/tmp/.mount_Subsurpq0Kcw/usr/translations"

$ ./Subsurface.AppImage
can't find Qt base localization for locale "pt-PT" searching in 
"/tmp/.mount_Subsur7l2t9d/usr/translations"


This does not happen for de_* or en_* (which are the other languages I 
tested). I also noticed that the "Save" etc. buttons in the preferences 
dialog are not translated for pt_*, this might be connected?


Best
Christof


On 26.03.22 22:29, Dirk Hohndel wrote:

There's a new pull request that addresses this.

https://github.com/subsurface/subsurface/pull/3425

English is special because en_US is always the fallback language. What 
we have hard-coded, though, is that our South African friends get 
British English :)


/D


On Mar 26, 2022, at 7:56 AM, Christof Arnosti  wrote:

Sounds good! :-)

if you're already implementing this, for Portuguese there are also 
two translation sets (pt_PT/pt_BR) with different completeness... 
Also en_GB/en_US? But I guess en_US is the source language, thus 
maybe only the plurals are translated in en_US?


Best
Christof

On 26.03.22 15:52, Dirk Hohndel wrote:
OK, I did some more searching and I think there is a clean solution 
- I'll try to implement this later today.


Qt indeed allows you to install multiple translations and will 
search them "last to first". So if we special case de_CH to first 
load de_DE and then load de_CH, we should get the intended behavior. 
It's surprisingly hard to find any documentation for this - I would 
have expected this to be something that a lot of people would like 
to take advantage of.


Stay tuned :)

/D


On Mar 25, 2022, at 8:31 AM, Christof Arnosti  wrote:

Am 25.03.22 um 16:03 schrieb Dirk Hohndel:



On Mar 25, 2022, at 7:46 AM, Christof Arnosti  
wrote:


Hi,

So, I now get where the problem with the missing Strings is 
coming from:


I'm using German (Switzerland) locale on my secondary computer. 
The German (Germany) translation is complete, but the German 
(Switzerland) translation is not.


I started copying the missing values from German (Germany) to 
German (Switzerland), but it's a boring manual process (transifex 
does not seem to provide bulk copying between two translated 
languages), and I suspect that in the future for new strings the 
same problem will arise. The difference between the two languages 
is very small, and to be honest, German (Switzerland) is not a 
very "relevant" dialect in the sense that people who can read 
German (Switzerland) are guaranteed to also be able to read 
German (Germany).


Before I continue my work: Would it be possible to have German 
(Germany) as fallback language for German (Switzerland)? Thus, if 
German (Switzerland) is selected, the order of strings would be 
"German (Switzerland) -> German (Germany) -> English" instead of 
"German (Switzerland) -> English"?




I don't know if THAT is possible. But I could trivially populate 
all the strings in the Swiss translation with the de_DE strings 
and have you just modify those that aren't the same. Would that 
work for you. I'd be able to do that this evening (so maybe 12 
hours from now) - I need to write a small script that does that 
and then upload the changes to Transifex.
This script would be a great help! Is there any way that I can 
quickly find the strings that were manipulated by your script 
afterwards?


With this solution, a reasonable user experience would be 
provided to German (Switzerland) users when Strings are updated, 
and the German (Switzerland) translation is missing. For the few 
strings that are different between German (Switzerland) and 
German (Germany), they could be overwritten in the German 
(Switzerland) translation. Maybe it wouldbe even better if German 
(Switzerland) would only contain the few strings that are 
different in the two dialects, so that Swiss users would also 
automatically get German (Germany) translation improvements...





I agree. Again, I don't think the infrastructure allows that.


Hmm... If it's easy to test, what would happen if you change the 
locale from "de_DE" to "de" for German (Germany)? I know some 
translation libraries work with this hierarchy...


Currently (before my translation updates today) the context menu of 
the dive list looks like this for de

Re: Subsurface 5.0.7 has been released

[Christof Arnosti via subsurface]

Sounds good! :-)

if you're already implementing this, for Portuguese there are also two 
translation sets (pt_PT/pt_BR) with different completeness... Also 
en_GB/en_US? But I guess en_US is the source language, thus maybe only 
the plurals are translated in en_US?


Best
Christof

On 26.03.22 15:52, Dirk Hohndel wrote:
OK, I did some more searching and I think there is a clean solution - 
I'll try to implement this later today.


Qt indeed allows you to install multiple translations and will search 
them "last to first". So if we special case de_CH to first load de_DE 
and then load de_CH, we should get the intended behavior. It's 
surprisingly hard to find any documentation for this - I would have 
expected this to be something that a lot of people would like to take 
advantage of.


Stay tuned :)

/D


On Mar 25, 2022, at 8:31 AM, Christof Arnosti  wrote:

Am 25.03.22 um 16:03 schrieb Dirk Hohndel:




On Mar 25, 2022, at 7:46 AM, Christof Arnosti  wrote:

Hi,

So, I now get where the problem with the missing Strings is coming 
from:


I'm using German (Switzerland) locale on my secondary computer. The 
German (Germany) translation is complete, but the German 
(Switzerland) translation is not.


I started copying the missing values from German (Germany) to 
German (Switzerland), but it's a boring manual process (transifex 
does not seem to provide bulk copying between two translated 
languages), and I suspect that in the future for new strings the 
same problem will arise. The difference between the two languages 
is very small, and to be honest, German (Switzerland) is not a very 
"relevant" dialect in the sense that people who can read German 
(Switzerland) are guaranteed to also be able to read German (Germany).


Before I continue my work: Would it be possible to have German 
(Germany) as fallback language for German (Switzerland)? Thus, if 
German (Switzerland) is selected, the order of strings would be 
"German (Switzerland) -> German (Germany) -> English" instead of 
"German (Switzerland) -> English"?




I don't know if THAT is possible. But I could trivially populate all 
the strings in the Swiss translation with the de_DE strings and have 
you just modify those that aren't the same. Would that work for you. 
I'd be able to do that this evening (so maybe 12 hours from now) - I 
need to write a small script that does that and then upload the 
changes to Transifex.
This script would be a great help! Is there any way that I can 
quickly find the strings that were manipulated by your script afterwards?


With this solution, a reasonable user experience would be provided 
to German (Switzerland) users when Strings are updated, and the 
German (Switzerland) translation is missing. For the few strings 
that are different between German (Switzerland) and German 
(Germany), they could be overwritten in the German (Switzerland) 
translation. Maybe it wouldbe even better if German (Switzerland) 
would only contain the few strings that are different in the two 
dialects, so that Swiss users would also automatically get German 
(Germany) translation improvements...





I agree. Again, I don't think the infrastructure allows that.


Hmm... If it's easy to test, what would happen if you change the 
locale from "de_DE" to "de" for German (Germany)? I know some 
translation libraries work with this hierarchy...


Currently (before my translation updates today) the context menu of 
the dive list looks like this for de_CH:




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

Re: Subsurface 5.0.7 has been released

[Christof Arnosti via subsurface]

Am 25.03.22 um 16:03 schrieb Dirk Hohndel:




On Mar 25, 2022, at 7:46 AM, Christof Arnosti  wrote:

Hi,

So, I now get where the problem with the missing Strings is coming from:

I'm using German (Switzerland) locale on my secondary computer. The 
German (Germany) translation is complete, but the German 
(Switzerland) translation is not.


I started copying the missing values from German (Germany) to German 
(Switzerland), but it's a boring manual process (transifex does not 
seem to provide bulk copying between two translated languages), and I 
suspect that in the future for new strings the same problem will 
arise. The difference between the two languages is very small, and to 
be honest, German (Switzerland) is not a very "relevant" dialect in 
the sense that people who can read German (Switzerland) are 
guaranteed to also be able to read German (Germany).


Before I continue my work: Would it be possible to have German 
(Germany) as fallback language for German (Switzerland)? Thus, if 
German (Switzerland) is selected, the order of strings would be 
"German (Switzerland) -> German (Germany) -> English" instead of 
"German (Switzerland) -> English"?




I don't know if THAT is possible. But I could trivially populate all 
the strings in the Swiss translation with the de_DE strings and have 
you just modify those that aren't the same. Would that work for you. 
I'd be able to do that this evening (so maybe 12 hours from now) - I 
need to write a small script that does that and then upload the 
changes to Transifex.
This script would be a great help! Is there any way that I can quickly 
find the strings that were manipulated by your script afterwards?


With this solution, a reasonable user experience would be provided to 
German (Switzerland) users when Strings are updated, and the German 
(Switzerland) translation is missing. For the few strings that are 
different between German (Switzerland) and German (Germany), they 
could be overwritten in the German (Switzerland) translation. Maybe 
it wouldbe even better if German (Switzerland) would only contain the 
few strings that are different in the two dialects, so that Swiss 
users would also automatically get German (Germany) translation 
improvements...





I agree. Again, I don't think the infrastructure allows that.


Hmm... If it's easy to test, what would happen if you change the locale 
from "de_DE" to "de" for German (Germany)? I know some translation 
libraries work with this hierarchy...


Currently (before my translation updates today) the context menu of the 
dive list looks like this for de_CH:




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

Re: Subsurface 5.0.7 has been released

[Christof Arnosti via subsurface]

Hi,

So, I now get where the problem with the missing Strings is coming from:

I'm using German (Switzerland) locale on my secondary computer. The 
German (Germany) translation is complete, but the German (Switzerland) 
translation is not.


I started copying the missing values from German (Germany) to German 
(Switzerland), but it's a boring manual process (transifex does not seem 
to provide bulk copying between two translated languages), and I suspect 
that in the future for new strings the same problem will arise. The 
difference between the two languages is very small, and to be honest, 
German (Switzerland) is not a very "relevant" dialect in the sense that 
people who can read German (Switzerland) are guaranteed to also be able 
to read German (Germany).


Before I continue my work: Would it be possible to have German (Germany) 
as fallback language for German (Switzerland)? Thus, if German 
(Switzerland) is selected, the order of strings would be "German 
(Switzerland) -> German (Germany) -> English" instead of "German 
(Switzerland) -> English"?


With this solution, a reasonable user experience would be provided to 
German (Switzerland) users when Strings are updated, and the German 
(Switzerland) translation is missing. For the few strings that are 
different between German (Switzerland) and German (Germany), they could 
be overwritten in the German (Switzerland) translation. Maybe it wouldbe 
even better if German (Switzerland) would only contain the few strings 
that are different in the two dialects, so that Swiss users would also 
automatically get German (Germany) translation improvements...


Best
Christof

Am 25.03.22 um 01:34 schrieb Dirk Hohndel:




On Mar 24, 2022, at 11:18 AM, Christof Arnosti  wrote:

I did my "usual" workflow (importing, editing divesite, 
editing/adding gear). I didn't notice anything breaking or worrying.




Yay! thank you


I did however notice two things:

- In the "Gears" tab, the columns are sometimes too narrow in the 
default settings (bottle type / lead type) to display the content of 
the dropdown in the list. This might be since with German language 
settings the title of the column is very short ("Typ")




We have always struggled having good default column widths. I keep 
thinking that I should work on that - and then there are a million 
other things to do. But yes, this has been a problem since forever.


- There seem to be some missing German strings. I just joined 
transifex so I might be able to put some work into German / Swiss 
German translations.




I added you. It's possible that the strings themselves aren't marked 
for translation.
It's always good to send screen shots if you run into issues like that 
- that way the rest of us can help figure out what's going on.


Thanks

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

Re: Subsurface 5.0.7 has been released

[Christof Arnosti via subsurface]

Thanks for the pointers, Dirk!

I did my "usual" workflow (importing, editing divesite, editing/adding 
gear). I didn't notice anything breaking or worrying.


I did however notice two things:

- In the "Gears" tab, the columns are sometimes too narrow in the 
default settings (bottle type / lead type) to display the content of the 
dropdown in the list. This might be since with German language settings 
the title of the column is very short ("Typ")
- There seem to be some missing German strings. I just joined transifex 
so I might be able to put some work into German / Swiss German translations.


Best
Christof

Am 24.03.22 um 17:15 schrieb Dirk Hohndel:
The main goals of testing Subsurface should typically be that the 
things that you tend to use work.


So ideally
- check the UI features you usually use; do you look at statistics? do 
you plan dives? do you... -- this way you test things that you are 
familiar with and will likely notice if something breaks... if I test 
the dive planner I go 🤷🏼‍♂️ :shrug: because I generally have no idea 
what to expect it to do

- make sure it successfully syncs with the cloud storage (if you use this)
- create a test dive log on the local system and download from one (or 
more) of your dive computers
- if you print things usually, test that still works and acts as 
expected (i.e., we didn't break your templates)

- etc

The idea here really is to make testing quick and easy for everyone. 
Just test the stuff you'd use anyway. And at the same time this 
creates very broad test coverage simply by the size of this team (as I 
said, more than 300 people). And by the very nature of the size of 
this team, we'll get coverage for the most commonly used platforms 
(with likely more Linux testing than in our overall user base :) )


Thanks for taking the time to read this - and hopefully for giving 
5.0.7.1 a quick spin.


/D


On Mar 24, 2022, at 1:18 AM, Christof Arnosti  wrote:

I just tried the AppImage on a very non-clean kubuntu installation 
where Subsurface was NOT formerly installed, and I could open my 
cloud log and see the pins on the map.


I didn't follow very closely, is there anything else to look out for?

Best
Christof

Am 24.03.22 um 09:00 schrieb Jason Bramwell via subsurface:

Using 5.0.7.1 the map is working again on this MacBook I was using yesterday. 
This is not an entirely clean machine but the only version it’s ever had is 
5.0.7.

Jason

Sent from my iPhone


On 24 Mar 2022, at 03:15, Dirk Hohndel via 
subsurface  wrote:

We have new test builds for 5.0.7.1

I have tested these on two clean macOS VMs (macOS 10.15 and 11.3) and on a 
physical Windows box.
I also tested a macOS Apple M1 Qt 6 build (I don't appear to have broken that).
And I tested the macOS x86 build on that M1 MBP.
Finally, I tested the AppImage on a fairly current Linux distro

I think this is actually working now, but I'd love for some of the more than 
300 people on this list to test those latest binaries on YOUR systems - because 
you have significantly more diversity of hardware and OS combinations than I 
have access to.

Thanks

/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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface 5.0.7 has been released

[Christof Arnosti via subsurface]

I just tried the AppImage on a very non-clean kubuntu installation where 
Subsurface was NOT formerly installed, and I could open my cloud log and 
see the pins on the map.


I didn't follow very closely, is there anything else to look out for?

Best
Christof

Am 24.03.22 um 09:00 schrieb Jason Bramwell via subsurface:

Using 5.0.7.1 the map is working again on this MacBook I was using yesterday. 
This is not an entirely clean machine but the only version it’s ever had is 
5.0.7.

Jason

Sent from my iPhone


On 24 Mar 2022, at 03:15, Dirk Hohndel via 
subsurface  wrote:

We have new test builds for 5.0.7.1

I have tested these on two clean macOS VMs (macOS 10.15 and 11.3) and on a 
physical Windows box.
I also tested a macOS Apple M1 Qt 6 build (I don't appear to have broken that).
And I tested the macOS x86 build on that M1 MBP.
Finally, I tested the AppImage on a fairly current Linux distro

I think this is actually working now, but I'd love for some of the more than 
300 people on this list to test those latest binaries on YOUR systems - because 
you have significantly more diversity of hardware and OS combinations than I 
have access to.

Thanks

/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___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Statistics code for desktop (and soon mobile)

[Christof Arnosti via subsurface]

Hi Dirk, hi together,

I'm not great in UI myself, but I've drawn out what I tried to put in
words. It's basically just moving some elements around, so they are more
grouped by functionality.

Basically I moved the constraints down. I aligned the Dropdown from the
Fulltext-Section with the "Add constraints"-button, but did not align
the items in the constraint-list with anything outside of the list (so
keep the list tabular, but don't align with the headers).

I did remove the bold "Filter" at the top left, since I think the Tab
header should be enough (but if a title should be present, maybe give it
it's own line?). I would also suggest that - if no constraint is
currently active - a "No constrains present"-Text should be displayed
where the constraints are otherwise.

Best regards
Christof


On 09.01.21 18:01, Dirk Hohndel via subsurface wrote:
> On Jan 8, 2021, at 15:13, Berthold Stoeger via subsurface 
>  wrote:
>>> On Freitag, 8. Jänner 2021 23:25:07 CET Christof Arnosti via subsurface 
>>> wrote: 
>>>  * When I select date(yearly) as base variable and buddies as data, bar
>>>charts have a yellow warning in the drop down. Why's that?
>> A bar-chart is not recommended with continuous data. A histogram is 
>> preferred. 
>> However, as you note, the warning icon is not a good UI element.
> BTW: since Berthold, Willem, and I are all three not necessarily the best UI 
> designers in the world... I’m curious if people have better idea for how to 
> mark “undesirable” charts. What Berthold has done with the warning triangle 
> has the advantage of being fairly easy to implement in Qt (because the widget 
> supports this concept of having a mark that you put on top of the icon and in 
> front of the text). But if someone has a stronger UI concept of how we should 
> do that, I’m sure one of us will try to wrestle Qt into submission to 
> implement that.
>
>>> * The trend line does not always appear in the scatter graph. For
>>>example, when I select date (no binning) / depth, there is no trend
>>>line, except for when I filter out very shallow depths. For water
>>>temp over date I get a trend line right away. I'm sure that's
>>>correct and there is a statistical reason for this that I'm not
>>>aware of.
>> Indeed, there is a statistical test whether there is a linear regression. 
>> Willem knows more.
> And, BTW, depending on which version exactly you tested, there were a couple 
> of binaries that had a bug that prevented valid regression lines from being 
> shown. The current binaries, however, no longer have that bug.
>
>>> * Is there some Export functionality planned? For example simple image
>>>export of the graph?
>> Not yet.
> I’ll admit that I always think “every OS has a well understood screen shot 
> function...”
> So this isn’t necessarily high on my personal list :-)
>
>>>  * For me the Filter GUI seems a bit unintuitive. When there is no
>>>constraint present, it's not very obvious that constraints can be
>>>added (the button is in an odd place). A change to make it more
>>>obvious could be to add a "Constraints" heading below the fulltext
>>>search, and move the button there? And maybe also display a "No
>>>constraints" text when no constraint is set? I really like the
>>>"Filter sets" functionality!
>> Yes, I also noticed that - especially in the German translation - the filter 
>> is quite inaccessible.
> See my earlier comment. We would be delighted to see visual mockups of what 
> you think would be a better UI. Literally, take a few colored pens/pencils, 
> draw on a piece of paper, send a cell phone pic. No need to try to create 
> this in software, just help us with better ideas...
>
>>>  * What I didn't find was an "Average depth" variable, this would maybe
>>>also be interesting to add.
>> I'm not sure if we currently track the average depth. I'm also not sure it 
>> is 
>> very well defined - what about surface intervals. Dirk?
> When people say “average depth” I always assume they are asking for the “mean 
> depth”.
> I’m not sure what I would do with a surface interval statistic - but hey, 
> what do I know, right?
>
>>> What would be really nice, but might be complicated to implement, would
>>> be to have a kind of "Zoom" or "Select" possibility to add constraints.
>>> For example my Depth over Date Scattergraph looks like this:
>>>
>>> Now to have a look at a single holiday I can add a cons

Re: Statistics code for desktop (and soon mobile)

[Christof Arnosti via subsurface]

Hi Berthold,

Thanks for your answer.

> I'm not sure if we currently track the average depth. I'm also not
sure it is very well defined - what about surface intervals. Dirk?

I meant average depth per dive. This is already present in the dive
information, and it's used to calculate SAC, so it should already be
defined.

> That is an interesting idea. But don't hold your breath. Currently we
are changing the rendering engine to port the statistics to mobile and
this will take some time.

I thought so, but I just wanted to plant a seed ;-)

> Note that there is a "year" filter constraint, which is quicker to use
than the general date-filter, if that is all the granularity that you need.

Thanks, I didn't realize that there is a "Year"-Filter.

Christof

On 09.01.21 00:13, Berthold Stoeger wrote:
> Hi Christof,
>
> Thank you for the detailed report. A few short comments in-line.
>
> On Freitag, 8. Jänner 2021 23:25:07 CET Christof Arnosti via subsurface 
> wrote: 
>>   * When I select date(yearly) as base variable and buddies as data, bar
>> charts have a yellow warning in the drop down. Why's that?
> A bar-chart is not recommended with continuous data. A histogram is 
> preferred. 
> However, as you note, the warning icon is not a good UI element.
>
> In case of sparse data I have likewise found bar charts to be more convenient 
> than histograms. On the other hand, I see the argument that they can be 
> misleading if only a few cups of data are missing.
>
>>   * The trend line does not always appear in the scatter graph. For
>> example, when I select date (no binning) / depth, there is no trend
>> line, except for when I filter out very shallow depths. For water
>> temp over date I get a trend line right away. I'm sure that's
>> correct and there is a statistical reason for this that I'm not
>> aware of.
> Indeed, there is a statistical test whether there is a linear regression. 
> Willem knows more.
>
>>   * When I select Buddies over Date(yearly), and then grouped vertical
>> bar chart, the bars are oddly spaced. I suspect that for every buddy
>> there is a bar every year, even if the number is zero. This might
>> make sense in some cases (for example water temperature), but in the
>> buddy case it looks weird. Maybe add some "don't show empty bars"
>> option for the grouped bar charts?
> I'm not an expert in charts, but I think that this is how grouped bar charts 
> should be done(?). In the case of sparse data a stacked chart is probably 
> preferred.
>
>>   * Is there some Export functionality planned? For example simple image
>> export of the graph?
> Not yet.
>
>>   * For me the Filter GUI seems a bit unintuitive. When there is no
>> constraint present, it's not very obvious that constraints can be
>> added (the button is in an odd place). A change to make it more
>> obvious could be to add a "Constraints" heading below the fulltext
>> search, and move the button there? And maybe also display a "No
>> constraints" text when no constraint is set? I really like the
>> "Filter sets" functionality!
> Yes, I also noticed that - especially in the German translation - the filter 
> is quite inaccessible.
>
>>   * What I didn't find was an "Average depth" variable, this would maybe
>> also be interesting to add.
> I'm not sure if we currently track the average depth. I'm also not sure it is 
> very well defined - what about surface intervals. Dirk?
>
>>   * "Dive number" as Base Variable would maybe make sense to show
>> changes over number of dives. This would be interesting for me since
>> I go diving once or maybe twice a year, so when I use non-binned
>> date as base variable, there are basically vertical lines in the
>> scatter plot (see below).
> That is trivial to implement and seems like a good idea.
>
>> What would be really nice, but might be complicated to implement, would
>> be to have a kind of "Zoom" or "Select" possibility to add constraints.
>> For example my Depth over Date Scattergraph looks like this:
>>
>> Now to have a look at a single holiday I can add a constraint over a
>> range of dates, for example 1.1.2017 to 1.1.2018. This works fine! But
>> the cherry on top would be if I could simply drag a rectangle over the
>> points in 2017, and set the constraints like this (Sort of a "Zoom into
>> range" functionality).
> That is an interesting idea. But don't hold your bre

Re: Statistics code for desktop (and soon mobile)

[Christof Arnosti via subsurface]

Same here. I just did give it a second go with the current AppImage
(which works perfectly now). I didn't find anything "buggy" and there
isn't much to complain about (the most German compliment ever). I like
it! :-)

I don't have too many dives (86), and everything is open circuit, so
it's maybe a bit harder to get interesting statistics, but I did find:

  * My SAC sucks and didn't get much better over the years, but gets
better at the end of the holidays. And less SAC in warmer water
(makes sense, but I didn't think about it before I played around here)
  * Dives with a higher max depth are shorter (duh)
  * Buddy counts (Interesting!), total and over the years.
  * In my first year I had a suspicious high number of dives reaching
exactly 18 meters...
  * And lots of other interesting insights.

It's really a nice feature to play around! But now I want to go diving :-(

Some Questions and remarks:

  * When I select date(yearly) as base variable and buddies as data, bar
charts have a yellow warning in the drop down. Why's that?
  * The trend line does not always appear in the scatter graph. For
example, when I select date (no binning) / depth, there is no trend
line, except for when I filter out very shallow depths. For water
temp over date I get a trend line right away. I'm sure that's
correct and there is a statistical reason for this that I'm not
aware of.
  * When I select Buddies over Date(yearly), and then grouped vertical
bar chart, the bars are oddly spaced. I suspect that for every buddy
there is a bar every year, even if the number is zero. This might
make sense in some cases (for example water temperature), but in the
buddy case it looks weird. Maybe add some "don't show empty bars"
option for the grouped bar charts?
  * Is there some Export functionality planned? For example simple image
export of the graph?
  * For me the Filter GUI seems a bit unintuitive. When there is no
constraint present, it's not very obvious that constraints can be
added (the button is in an odd place). A change to make it more
obvious could be to add a "Constraints" heading below the fulltext
search, and move the button there? And maybe also display a "No
constraints" text when no constraint is set? I really like the
"Filter sets" functionality!
  * What I didn't find was an "Average depth" variable, this would maybe
also be interesting to add.
  * "Dive number" as Base Variable would maybe make sense to show
changes over number of dives. This would be interesting for me since
I go diving once or maybe twice a year, so when I use non-binned
date as base variable, there are basically vertical lines in the
scatter plot (see below).

What would be really nice, but might be complicated to implement, would
be to have a kind of "Zoom" or "Select" possibility to add constraints.
For example my Depth over Date Scattergraph looks like this:

Now to have a look at a single holiday I can add a constraint over a
range of dates, for example 1.1.2017 to 1.1.2018. This works fine! But
the cherry on top would be if I could simply drag a rectangle over the
points in 2017, and set the constraints like this (Sort of a "Zoom into
range" functionality).

Best regards
Christof

On 08.01.21 21:42, Martin de Weger via subsurface wrote:
> I have played with it a bit, and it looks great. I haven’t looked into
> it deep enough to say I actually tested it. 
>
>>
>> Op 8 jan. 2021 om 21:33 heeft Dirk Hohndel via subsurface
>>  het volgende geschreven:
>>
>> 
>>
>>> On Jan 3, 2021, at 5:17 PM, Dirk Hohndel >> > wrote:
>>>
>>>
>>>
 On Jan 3, 2021, at 3:44 PM, Dirk Hohndel via subsurface
 >>> > wrote:

 Right, I didn't test the AppImage. Silly me. I'll add that to my list.
>>>
>>> AppImage is fixed, also Subsurface now reacts more gracefully if the
>>> QtCharts QML modules can't be found.
>>> Instead of a crash the statistics chart is simply empty. What we
>>> really need is a reasonable error message (or alternative disable
>>> the statistics entry in the menu.
>>> But this is at least a step in the right direction.
>>>
>>> New AppImage should appear in downloads/test in the next few minutes
>>> as Subsurface-v4.9.10-235-gc63994f77-x86_64.AppImage
>>> This one was tested on a couple of different Linux flavors...
>>
>> So we have working binaries for all platforms, but we have heard
>> basically no feedback on the new statistics feature.
>> No indication that anyone has tested this, likes it, hates it, has
>> suggestions.
>>
>> It's really hard to develop in a vacuum. And it's a bit frustrating, too.
>>
>> I know that guilt-tripping people into doing things simply doesn't
>> work. Berthold, Willem, and I will continue to just work along.
>> But we sure would appreciate some input. Even if it is just a simple
>> "this is the best software ever written in the unive

Re: RFC: Statistics in Subsurface

[Christof Arnosti via subsurface]

Hi Dirk,

Thanks for your response.

Am 14.05.20 um 18:37 schrieb Dirk Hohndel:
> Hi Chrisof
>
>> On May 14, 2020, at 3:30 AM, Christof Arnosti > > wrote:
>>
>> Let me give some thoughts from a more-or-less outsider perspective in
>> this discussion.
>>
>> From a UI-Perspective, I would prefer the layout to be "Dive List top
>> left", "Filter top right", "Stats selection bottom left", "Stats
>> display bottom right". This is with the reasoning that (in the
>> western world) we work from top left, top right, bottom left, bottom
>> right, and the logical Workflow would be to have the dive list as
>> input, which is then filtered, then the statistics selected and
>> finally the output. This workflow could also be applied as sort of a
>> wizard for mobile devices.
>>
>
> In insulation that may be true. But our existing UI is not up for
> discussion. And that very intentionally has the information that the
> user interacts with (information tabs and profile) on top, and the
> selection of dives on the bottom. Switching that around to show
> statistics would lead to a horrible user experience.
I see. Makes sense to be consistent here.
>
> On mobile these would have to be different pages, anyway, so there the
> 'layout' question is fairly moot
Agree.
>
>> For selecting the graph type (the bar vs boxplot discussion): Could
>> this also be implemented as an option in the "Stats selection"
>> section? I think it's obvious that some people prefer the more
>> advanced boxplot version, and some the easier to understand bar/line
>> graph version.
>>
>
> Every time we opt for "oh, let's make this selectable" we
> significantly increase the amount of code that needs to be written and
> tested, and we make the UI more complicated by adding more options.
> We already have way, way, way too many options. And we constantly find
> that yet some other feature has bit-rotted and doesn't work anymore.
> Or that some changes to our code break something else that doesn't
> have an active developer anymore.
>
> Today Subsurface is de facto maintained by about five people, three of
> which contribute in very narrow slices that are "theirs", and the
> other two (Berthold and I) try to keep everything else working.
Makes sense. Bitrot is a pain I just know too good (I'm currently
procastrinating to fix some legacy C++ code on a microcontroller that
won't cooperate with updated host software... The horrors!).
>
>> Another (third? fourth?) option I just tought of was a boxplot with
>> included histogram, where the histogram is displayed as color
>> (instead of a curve). I have attached an image of a short mockup
>> (Where red means more, and green means less). I'm not sure if that's
>> a good idea, but at least it's an idea ;-)
>>
>
> It's definitely an idea. It's geeky and cool. I don't think it will
> help accessibility (in the sense of being easy to understand for the
> casual user).
I agree, if there is no selectable graph style this should NOT be the one.
>
>> About graph orientation: I strongly agree that the bars (or boxes or
>> whatever) should be vertical, so that the time-axis (or trip axis or
>> whatever) is the z axis.
>>
>
> You mean time / categories should be the x axis, correct?
Yes, exactly. Sorry for confusing X/Z. For me it's just way more natural
to process data from left to right instead of top to bottom, especially
if it's time-based (which I think it will be in the most cases -
categorizing by trips will probably also be sorted by time?).
>
>> This is (at least for me) the natural way to read graphs, and also
>> what's currently done in the dive-display.
>>
>
> Which dive display? The dive list has time as the vertical axis. Do
> you mean the dive profile? That's a single dive, not a collection of
> dives. Very different.
Yes, the dive profile. I know it's a different thing, but still it's a
graph and time is on the x axis. I think this would add some additional
confusion if there are differently-oriented graphs.
>
>> And as a last point a proposal for a little visual gimmick: I would
>> really like to have the value-axis for depth turned around, so that
>> the 0-point is on top of the graph (like in the current dive-graph).
>> With this, the visual representation of the data is the same as in
>> the physical reality, lower means lower.
>>
>
> Yes, that makes perfect sense for a dive plot (which is why we do it
> that way). For statistics I would find it absolutely painful.
I wouldn't ;-) But as said, it's just a gimmick.
>
> /D 
Best regards
Christof
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: RFC: Statistics in Subsurface

[Christof Arnosti via subsurface]

Hi together,

Thank you very much for the verry nice mockup, Pedro! I really like
this!

Let me give some thoughts from a more-or-less outsider perspective in
this discussion.

From a UI-Perspective, I would prefer the layout to be "Dive List top
left", "Filter top right", "Stats selection bottom left", "Stats display
bottom right". This is with the reasoning that (in the western world) we
work from top left, top right, bottom left, bottom right, and the
logical Workflow would be to have the dive list as input, which is then
filtered, then the statistics selected and finally the output. This
workflow could also be applied as sort of a wizard for mobile devices.

For selecting the graph type (the bar vs boxplot discussion): Could this
also be implemented as an option in the "Stats selection" section? I
think it's obvious that some people prefer the more advanced boxplot
version, and some the easier to understand bar/line graph version.

Another (third? fourth?) option I just tought of was a boxplot with
included histogram, where the histogram is displayed as color (instead
of a curve). I have attached an image of a short mockup (Where red means
more, and green means less). I'm not sure if that's a good idea, but at
least it's an idea ;-)

About graph orientation: I strongly agree that the bars (or boxes or
whatever) should be vertical, so that the time-axis (or trip axis or
whatever) is the z axis. This is (at least for me) the natural way to
read graphs, and also what's currently done in the dive-display.

And as a last point a proposal for a little visual gimmick: I would
really like to have the value-axis for depth turned around, so that the
0-point is on top of the graph (like in the current dive-graph). With
this, the visual representation of the data is the same as in the
physical reality, lower means lower.

Best regards
Christof

Am 13.05.20 um 21:19 schrieb Dirk Hohndel via subsurface:
> Wow, that's a VERY cool mockup.
>
> I had considered taking over the top two panes of our display; dive
> list on the lower left. Filter (hopefully with the new, incremental
> UI) on the lower right. The selection of statistics (drop downs) top
> left, graph top right.
>
> But the flow that you describe sounds right to me.
>
> /D
>
>> On May 13, 2020, at 11:43 AM, Pedro Neves > > wrote:
>>
>> On 13/05/20 16:36, Dirk Hohndel via subsurface wrote:
>>>
>>> Yes, this was intended as an example for 'by time'.
>>> And no, I suck as a UI designer.
>>> But I've also learned that we cannot start creating a UI without
>>> having a decent idea of how it's supposed to look.
>>
>>
>> Dirk:
>>
>> Is something like this what you had in mind? I kind of like your
>> reasoning in what concerns the workflow:
>>
>> 1. Select:
>>
>> 1.1 select variables;
>>
>> 1.2. select grouping;
>>
>> 1.3. select granularity;
>>
>> 2. Filter dives based on selected criteria;
>>
>> 3. Calculate stats;
>>
>> 4. Display results based on chosen stats.
>>
>> Is this what you have in mind, or am I missing it?
>>
>> Cheers:
>>
>> Pedro
>>
>
>
>
> ___
> 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: Suunto HelO2 - successful

[Christof Arnosti via subsurface]

Hi Linus,

The changes (done by Dirk) that fixed the "cloudless"-problem I had were
not published in the Play Store Beta until some hours ago. Now they
should be online, and are very likely to also fix your problem with the
cloud synchronisation.

I've just implemented the wakelock (which should keep the CPU of an
android device awake during some processing while the screen is off) and
a couple unrelated changes at
https://github.com/Subsurface-divelog/subsurface/pull/2668. Could you
retest the HelO2-Download on the Pixel 4 with screen-timeout, and check
if now all dives are transferred? The CI-Built android app can be
downloaded at
https://github.com/Subsurface-divelog/subsurface/suites/521405640/artifacts/2916106.

Best regards
Christof

Am 13.03.20 um 23:10 schrieb Linus Torvalds:
>
>
> On Fri, Mar 13, 2020, 15:00 Linus Torvalds
> mailto:torva...@linux-foundation.org>>
> wrote:
>
>
> And again: I didn't look at the drive data itself, other than
> verifying that it looked sane in the list for dates and depths.
> The dives were from 4+ years ago...
>
>
> Hmm.  In order to look at the data, I decided to just try to sync to
> the cloud and do it what way
>
> When I enabled automatic cloud sync it crashes for me when trying to
> send the result to the cloud :-(
>
> I had to uninstall and reinstall the app because it just kept crashing
> at startup..
>
>       Linus
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto HelO2 - successful

[Christof Arnosti via subsurface]

Hi Linus,

Hmm... This does not sound directly related to the usb download.

There was a (similar?) problem with local storage I stumbled upon some
days ago (https://github.com/Subsurface-divelog/subsurface/issues/2667).
This was present in 4.9.3.1137. Dirk did fix it, but I'm not sure if the
current version in the play store beta channel already has this fix.

Best regards
Christof

Am 13.03.20 um 23:10 schrieb Linus Torvalds:
>
>
> On Fri, Mar 13, 2020, 15:00 Linus Torvalds
> mailto:torva...@linux-foundation.org>>
> wrote:
>
>
> And again: I didn't look at the drive data itself, other than
> verifying that it looked sane in the list for dates and depths.
> The dives were from 4+ years ago...
>
>
> Hmm.  In order to look at the data, I decided to just try to sync to
> the cloud and do it what way
>
> When I enabled automatic cloud sync it crashes for me when trying to
> send the result to the cloud :-(
>
> I had to uninstall and reinstall the app because it just kept crashing
> at startup..
>
>       Linus
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto HelO2 - successful

[Christof Arnosti via subsurface]

Hi together,

Linus, thanks for testing and reporting the screen lock problem. Happy
to hear that another Suunto computer works!

Anton, I had a short google search for the sreen lock problem Linus
reported, and the wakelock indeed seems to be the problem. I just did a
short (20s) test with sending the app into background, and the download
did continue in the background. When I got back into subsurface, even
the status was still updated. I can't reproduce the problem with
automatic screen locking since I don't have enought dives on my computer.

I will try to do some work on subsurface tomorrow, and will also
implement the wakelock at this opportunity.

Best regards
Christof

Am 13.03.20 um 23:04 schrieb Anton Lundin:
> On 13 March, 2020 - Linus Torvalds via subsurface wrote:
>
>> So I just tried downloading from my old Suunto HelO2 on android
>> mobile, and it all seemed to work fine.
>>
>> I did notice something: if I left my phone alone (because I did the
>> "force download all dives" and it took a while), the download seemed
>> to get truncated. I didn't really test a lot, but my _guess_ is that
>> when the lock-screen comes on, the access to the USB device gets
>> terminated.
>>
>> If I kept the phone open (touching it to keep things awake) it did
>> seem to download all (?) 48'ish dives. I haven't used that dive
>> computer in a long time by now, so I'm not actually sure how many
>> dives it has on it, but it seemed believable.
>>
>> I tried to email myself the logs (with the "Help -> Ask for support"
>> thing) but that only sent a very truncated set of logs. Nothing
>> interesting.
>>
>> That's with the official Suunto cable, and the phone immediately asked
>> me "Do I want to start subsurface" when I connected it.
>>
>> Anyway, aside from the fact that none of the dives were new and I
>> didn't check the details, it all looked successful. With the caveat
>> that apparently  you can't close the screen.
>>
>> I didn't try locking/unlocking by hand while downloading. I guess I should.
> I'm guessing we should hold a wake lock while downloading.
>
> I wonder what happens if one starts a download and then sends the app
> into the background, and goes off to do something else. Will our code
> still get scheduled or will we get suspended and the download will fail?
>
>
> //Anton - Who might actually test this...
>
>

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

Re: Suunto D4i - old not Novo with Sunnto cable

[Christof Arnosti via subsurface]

Thanks, that's nice to hear! :)

Am 13.03.20 um 17:22 schrieb John Smith via subsurface:
> Connected watch to Lenovo tablet running Android 9 - opened Subsurface
> automatically and completed some entries , still had to select D4i,
> downloaded 4 missing dives, no issues at all
>
>
>
> ___
> 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: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi Miika,

Just a short question: Did you use the same cable for both the D4 and
the Vyper? If not, could you also send me the PID/VID of the Vyper cable?

Thanks
Christof

On 10.03.20 09:12, Miika Turkia wrote:
> Well, what do you know, everything worked with logcat running. Both D4
> and Vyper Air started downloading fine. D4 ran all the way through.
> Vyper I terminated after a few dives were loaded. Will do more testing
> when I have time.
>
>> On 10. Mar 2020, at 7.40, Miika Turkia  wrote:
>>
>> 
>> I should be able to run logcat once I have collected more test data.
>> I just need to figure out how to do that over wifi or BT. Have always
>> connected with usb cable before, but that is not an option this time :)
>>
>> BTW I just realized that Garmin is not supported, but it should
>> probably be relatively easy to add. It is mounted as a disk and we
>> need to just point to right mount point. Or am I missing something?
>>
>>> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
>>>
>>> 
>>>
>>> Hi,
>>>
>>> Thanks. The Info (idVendor / idProduct) is already in the log you
>>> sent, so no need to download the app.
>>>
>>> I want to get some (more or less) statistical data about which
>>> usb-to-serial chipset behaves how. This is a big help! :)
>>>
>>> If you have some experience in the android world, could you maybe
>>> try to run "adb logcat" while downloading the dives? The logcat
>>> output might help with pinpointing the application crash, and I
>>> think until now yours is the only report of an actual application crash.
>>>
>>> Best regards
>>> Christof
>>>
>>> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>>>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface
>>>> >>> <mailto:subsurface@subsurface-divelog.org>> wrote:
>>>>
>>>> Thanks for the more in-depth ;-) test.
>>>>
>>>> Having a look at the serial-interface chipset-list at
>>>> http://libdivecomputer.org/drivers.html I noticed that suunto
>>>> uses two different chipsets. Maybe this could be a lead to
>>>> follow up?
>>>>
>>>> Can the people owning a suunto computer maybe post the Vendor
>>>> ID / Product ID of their cable, and if it works or not? The
>>>> App 
>>>> 
>>>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
>>>> shows these values.
>>>>
>>>> This is what I get on dmesg when attaching the D4 cable:
>>>> ---8<---
>>>> [30804.146977] usb 1-2: new full-speed USB device number 12 using
>>>> xhci_hcd
>>>> [30804.301648] usb 1-2: New USB device found, idVendor=0403,
>>>> idProduct=6001
>>>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=0
>>>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>>>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>>>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>>>> [30804.890187] usbserial: USB Serial support registered for FTDI
>>>> USB Serial Device
>>>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter
>>>> detected
>>>> [30804.890728] usb 1-2: Detected FT232RL
>>>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now
>>>> attached to ttyUSB0
>>>> ---8<---
>>>>
>>>> Downloading from D4 with this cable on Android 7.1.1, the
>>>> Subsurface crashes after about 4 dives. Do you think the OTG cable
>>>> plays a part on this? I can try the app you mention if that would
>>>> be beneficial.
>>>>
>>>> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi,

Thanks. The Info (idVendor / idProduct) is already in the log you sent,
so no need to download the app.

I want to get some (more or less) statistical data about which
usb-to-serial chipset behaves how. This is a big help! :)

If you have some experience in the android world, could you maybe try to
run "adb logcat" while downloading the dives? The logcat output might
help with pinpointing the application crash, and I think until now yours
is the only report of an actual application crash.

Best regards
Christof

Am 09.03.20 um 23:39 schrieb Miika Turkia:
> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface
>  <mailto:subsurface@subsurface-divelog.org>> wrote:
>
> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses
> two different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID /
> Product ID of their cable, and if it works or not? The App 
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
> This is what I get on dmesg when attaching the D4 cable:
> ---8<---
> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
> [30804.301648] usb 1-2: New USB device found, idVendor=0403,
> idProduct=6001
> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
> [30804.301660] usb 1-2: Manufacturer: Smartinterface
> [30804.890118] usbcore: registered new interface driver ftdi_sio
> [30804.890187] usbserial: USB Serial support registered for FTDI USB
> Serial Device
> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
> [30804.890728] usb 1-2: Detected FT232RL
> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached
> to ttyUSB0
> ---8<---
>
> Downloading from D4 with this cable on Android 7.1.1, the Subsurface
> crashes after about 4 dives. Do you think the OTG cable plays a part
> on this? I can try the app you mention if that would be beneficial.
>
> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Thanks for the more in-depth ;-) test.

Having a look at the serial-interface chipset-list at
http://libdivecomputer.org/drivers.html I noticed that suunto uses two
different chipsets. Maybe this could be a lead to follow up?

Can the people owning a suunto computer maybe post the Vendor ID /
Product ID of their cable, and if it works or not? The App 
https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
shows these values.

Best regards
Christof

Am 09.03.20 um 23:20 schrieb Matt Thompson via subsurface:
>
> On Mon, Mar 9, 2020 at 3:40 PM Christof Arnosti via subsurface
>  <mailto:subsurface@subsurface-divelog.org>> wrote:
>
> Hi everybody,
>
> There seems to be some general problems with Suunto dive computer
> synchronisation.
>
> We got reports so far from the following Suunto computers which
> use some different libdivecomputer-classes (according to
> 
> https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):
>
> - Suunto Zoop (uses SUUNTO_VYPER): Does not work. After
> Timeout-Fix: First read returns size=0
> - Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after
> about 4 downloaded drives. There should be a mail with logs in the
> support mail address.
> - Suunto D4i (uses SUUNTO_D9): Report of working download
> - Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on
> "Connecting", might be because of unofficial cable.
>
> The "sleep and purge to surpress possible echo" thing seems to be
> exclusive to the suunto_vyper computers.
>
> What I find interesting is that the D4 and D4i (which are using
> the same driver suunto_d9) have different results.
>
> For my first round of testing with the D4i, I didn't have any new
> dives so I was tecnically only reporting that the communication was
> successful. I did a force download of all dives on my D4i and was able
> to successfully download ~150 dives.  I didn't check profiles but the
> dates and times looked reasonable.
>
>
> ___
> 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: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi everybody,

There seems to be some general problems with Suunto dive computer
synchronisation.

We got reports so far from the following Suunto computers which use some
different libdivecomputer-classes (according to
https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):

- Suunto Zoop (uses SUUNTO_VYPER): Does not work. After Timeout-Fix:
First read returns size=0
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4
downloaded drives. There should be a mail with logs in the support mail
address.
- Suunto D4i (uses SUUNTO_D9): Report of working download
- Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on "Connecting",
might be because of unofficial cable.

The "sleep and purge to surpress possible echo" thing seems to be
exclusive to the suunto_vyper computers.

What I find interesting is that the D4 and D4i (which are using the same
driver suunto_d9) have different results.

For better debugging I think Jef is right that it would be really nice
to have timestamps in the libdc-logs. I attached a possible patch
(porting of logfunc from libdivecomputer to libdivecomputer.c), but I'm
currently away from my main computer. Maybe somebody could give it a try
if it compiles and produces timestamps? With this we can check if the
read-function still returns too early for whatever reason.

Best regards
Christof


Am 09.03.20 um 11:19 schrieb Stephen Goodall:
> Hi christof,
> I'm still getting "failed to receive answer" for the Suunto, Cressi is
> still working so the timeout change is good for that one and hasn't
> broken it or anything. Is the version below the correct one?
>
> Suunto:
>
> Subsurface: v4.9.3-1050-g38ca3f684202, built with libdivecomputer
> v0.7.0-devel-Subsurface-NG (0714e327b70bb08f5289c9781c09dc10884881c9)
> INFO: Open: transport=1
> INFO: Configure: baudrate=2400, databits=8, parity=1, stopbits=0,
> flowcontrol=0
> INFO: Timeout: value=1000
> INFO: DTR: value=1
> INFO: Sleep: value=100
> INFO: Purge: direction=3
> INFO: Sleep: value=500
> INFO: RTS: value=1
> INFO: Write: size=5, data=0500161407
> INFO: Sleep: value=200
> INFO: Purge: direction=1
> INFO: RTS: value=0
> INFO: Read: size=0, data=
> ERROR: Failed to receive the answer. [in
> /__w/subsurface/subsurface/libdivecomputer/src/suunto_vyper.c:212
> (suunto_vyper_transfer)]
>
>
> Is there any way to get more verbose libdivecomputer logs or something?
>
> Cheers
>
>
>
> On Mon, 9 Mar 2020, 2:26 am Christof Arnosti,  > wrote:
>
> Hi Stephen,
>
> The build with the improved timeout handling is finished, the
> result is at
> 
> https://github.com/Subsurface-divelog/subsurface/suites/506855270/artifacts/2655791
> . Can you test again with your computers?
>
> Thanks
> Christof
>
> On 08.03.20 15:38, Christof Arnosti wrote:
>>
>> So I just opened a pull request
>> (https://github.com/Subsurface-divelog/subsurface/pull/2656).
>> With this the CI will build the updated version and we can test
>> again with our computers. The Mares Puck Pro still works as expected.
>>
>> Best regards
>> Christof
>>
>> On 08.03.20 14:39, Christof Arnosti wrote:
>>>
>>> Hi Jef,
>>>
>>> Thanks for your comments.
>>>
>>> On 08.03.20 09:27, Jef Driesen wrote:
 On 8/03/2020 06:31, Dirk Hohndel wrote:
>> On Mar 7, 2020, at 9:17 PM, Stephen Goodall
>> > 
>> 
>> > wrote:
>> Subsurface: v4.9.3-1049-g4529add7053f, built with
>> libdivecomputer v0.7.0-devel-Subsurface-NG
>> (0714e327b70bb08f5289c9781c09dc10884881c9)
>> INFO: Open: transport=1
>> INFO: Configure: baudrate=2400, databits=8, parity=1,
>> stopbits=0, flowcontrol=0
>> INFO: Timeout: value=1000
>> INFO: DTR: value=1
>> INFO: Sleep: value=100
>> INFO: Purge: direction=3
>> INFO: Sleep: value=500
>> INFO: RTS: value=1
>> INFO: Write: size=5, data=0500161407
>> INFO: Sleep: value=200
>> INFO: Purge: direction=1
>> INFO: RTS: value=0
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: siz

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Matt,

Thanks for testing! :-)

Unfortunately the Atomic Aquatics Cobalt 2 doesn't use a USB-to-Serial
interface, so this change doesn't do anything for it.

There is some (unrelated) work done by Dirk to fix the support for
directly connected USB devices in
https://github.com/Subsurface-divelog/subsurface/pull/2309.

Best regards
Christof


Am 08.03.20 um 17:04 schrieb Matt Thompson via subsurface:
>
> On Sat, Mar 7, 2020 at 2:12 PM Dirk Hohndel via subsurface
>  > wrote:
>
>
>
> > On Mar 7, 2020, at 8:46 AM, Stephen Goodall
>  > wrote:
> >
> > Hi Christof,
> > The Cressi worked 😁
> > The Suunto said there was an error (attached) - I've not used
> this on my phone before as it's my partner's computer so it's
> possible that I'm doing something wrong with it! It did read it
> and show the device ID so it must be talking to it.
>
> Can you please try again with the Suunto, and after you get the
> error, instead of taking a screen shot, please submit a support
> request from the app - this will copy the logs into your email
> program. You can send that email to the support address that
> auto-populates, or you can change the 'To' address and send it to
> the mailing list... but this will give us more detailed logs that
> might tell us what's going wrong.
>
>
> /D
> ___
>
>
> I just tried the new beta installed from the Play Store today.  I was
> able to successfully connect to a Suunto D4i using the official Suunto
> cable and also an Aqua Lung i750TC using the new usb-serial setup. I
> was not able to connect to my Atomic Aquatics Cobalt 2.  The status
> only ever said Connecting... and I gave up after a couple of minutes. 
> I sent the logs to the support address but I don't think there's
> anything of interest in there.
>
> Nice work!  One step closer to not needing a computer on dive trips
> anymore!
>
>
> ___
> 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 Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Stephen,

On 07.03.20 17:46, Stephen Goodall wrote:
> Hi Christof,
> The Cressi worked 😁
Good to hear!
> The Suunto said there was an error (attached) - I've not used this on
> my phone before as it's my partner's computer so it's possible that
> I'm doing something wrong with it! It did read it and show the device
> ID so it must be talking to it.

Not so good to hear...

I'm sure you did it the right way, but Suunto Zoop and Suunto Zoop Novo
use different driver classes, you did select the correct one?

Sadly libdivecomputer is built with logging disabled for subsurface, so
the generic error message "Dive data import error" is the only thing I
get here, and from this I don't really have a point to start working on.
@Dirk: Since I would expect that there might be quite some errors when
trying to import with the new method, would it be possible to enable
libdivecomputer-logging for android builds? Also, would these messages
also end up in the log which is accessible from inside the application?

Best regards
Christof

>
> On both of them, the intent thing pops up and the Cressi/Suunto is pre
> selected still like it used to. I just picked the model and the usb
> serial option, then force download all dives to be sure.
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:26 am Christof Arnosti,  > wrote:
>
> Hi Stephen,
>
> I hope that it will work with most computers using usb-to-serial
> interfaces. The underlying usb-serial-for-android implementation
> supports quite some chipsets.
>
> I'd love for you to test the implementation!
>
> You can grab a CI-Built apk from
> 
> https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
> for testing. The source can be found at
> https://github.com/charno/subsurface/tree/android-serial-clean,
> the pull request at
> https://github.com/Subsurface-divelog/subsurface/pull/2647.
>
> Best regards
> Christof
>
> On 07.03.20 17:22, Stephen Goodall wrote:
>> Will this affect all USB computers with Android? Very exciting!!
>> I had a look but made no progress (C++ is not something I've
>> worked with so it would have been a miracle if I had made
>> progress :D )
>>
>> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9
>> phone if you want me to test those out with any changes. Let me
>> know the branch and I can build it and test it out
>>
>> Cheers!
>>
>> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface,
>> > > wrote:
>>
>>
>>
>>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti
>>> mailto:cha...@charno.ch>> wrote:
>>>
>>> Hi Dirk,
>>>
>>> I did the integration of the Icon HD VID/PID pair, so if the
>>> testing is successful I think there is nothing left for me
>>> to do before a merge.
>>>
>>
>> I will play with this in a couple of hours and most likely
>> merge your changes.
>>
>>> Someone just tested with an Mares Nemo Wide (Serial <
>>> 5), and it did also work.
>>>
>>
>> Excellent.
>>
>>> Just for clarification about the possible UI changes (now
>>> that I'm more awake again), I would envision a workflow like
>>> this:
>>> - When opening the divecomputer-screen, or pressing the
>>> refresh button ("Neu Scannen" in german), get all UsbDevices
>>> by issuing UsbManager.getDeviceList(). Use these to populate
>>> the connection ("Verbindung") list. (Only show the entries
>>> with specified driver-class when this is activated in the
>>> settings). I think there has to be done some work in the
>>> bt-discovery part so that these two mechanisms can work
>>> together.
>>>
>>
>> I'm not sure what you mean by only showing the entries with a
>> specified driver class. I thought the driver class is
>> something that you would select in that Connection drop down
>> as an alternative to the found devices.
>> My guess is that on the vast, vast majority of Android
>> devices you will only ever get one USB device. Maybe if
>> someone uses a hub for some reason (maybe to power the phone
>> while reading dives?) one might see more, but in general that
>> would surprise me.
>> So we should optimize the user experience for the common
>> case. Which means to try and identify the one USB serial
>> device that is connected.
>>>
>>> - When a device from the connection list is selected, maybe
>>> try to guess Vendor / Model by data provided in the
>>> UsbDevice-Object. There is already some code in
>>> QMLManager::showDownloadPage. I'm not sure how much there
>>> can be done since it seems that a lot of devices use the
>>> same PID/VIDs.
>>>
>>
>> Correct - I played with th

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Stephen,

I hope that it will work with most computers using usb-to-serial
interfaces. The underlying usb-serial-for-android implementation
supports quite some chipsets.

I'd love for you to test the implementation!

You can grab a CI-Built apk from
https://github.com/Subsurface-divelog/subsurface/suites/505662208/artifacts/2634973
for testing. The source can be found at
https://github.com/charno/subsurface/tree/android-serial-clean, the pull
request at https://github.com/Subsurface-divelog/subsurface/pull/2647.

Best regards
Christof

On 07.03.20 17:22, Stephen Goodall wrote:
> Will this affect all USB computers with Android? Very exciting!! I had
> a look but made no progress (C++ is not something I've worked with so
> it would have been a miracle if I had made progress :D )
>
> I've got a Cressi Leonardo and a Suunto Zoop, and an Android 9 phone
> if you want me to test those out with any changes. Let me know the
> branch and I can build it and test it out
>
> Cheers!
>
> On Sun, 8 Mar 2020, 3:14 am Dirk Hohndel via subsurface,
>  > wrote:
>
>
>
>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti > > wrote:
>>
>> Hi Dirk,
>>
>> I did the integration of the Icon HD VID/PID pair, so if the
>> testing is successful I think there is nothing left for me to do
>> before a merge.
>>
>
> I will play with this in a couple of hours and most likely merge
> your changes.
>
>> Someone just tested with an Mares Nemo Wide (Serial < 5), and
>> it did also work.
>>
>
> Excellent.
>
>> Just for clarification about the possible UI changes (now that
>> I'm more awake again), I would envision a workflow like this:
>> - When opening the divecomputer-screen, or pressing the refresh
>> button ("Neu Scannen" in german), get all UsbDevices by issuing
>> UsbManager.getDeviceList(). Use these to populate the connection
>> ("Verbindung") list. (Only show the entries with specified
>> driver-class when this is activated in the settings). I think
>> there has to be done some work in the bt-discovery part so that
>> these two mechanisms can work together.
>>
>
> I'm not sure what you mean by only showing the entries with a
> specified driver class. I thought the driver class is something
> that you would select in that Connection drop down as an
> alternative to the found devices.
> My guess is that on the vast, vast majority of Android devices you
> will only ever get one USB device. Maybe if someone uses a hub for
> some reason (maybe to power the phone while reading dives?) one
> might see more, but in general that would surprise me.
> So we should optimize the user experience for the common case.
> Which means to try and identify the one USB serial device that is
> connected.
>>
>> - When a device from the connection list is selected, maybe try
>> to guess Vendor / Model by data provided in the UsbDevice-Object.
>> There is already some code in QMLManager::showDownloadPage. I'm
>> not sure how much there can be done since it seems that a lot of
>> devices use the same PID/VIDs.
>>
>
> Correct - I played with that back when working on the Intent code
> and while there are a couple you can explicitly identify, for most
> that is not possible
>
>> - When the download-button is pressed, the UsbDevice-Object of
>> the selected connection (and if selected the name of the
>> driver-class) should be passed to serial_android_usb_open. From
>> there on I can do the work.
>>
>
> So again, you are suggesting to have a second (or actually,
> fourth?) drop down with a driver class?
>
>> There would probably also have to be done some changes when
>> receiving the USB_DEVICE_ATTACHED intent so that the correct
>> entry of the list is preselected.
>>
>
> I believe so.
>
> /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 Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

On 07.03.20 17:12, Dirk Hohndel wrote:
>
>
>> On Mar 7, 2020, at 5:27 AM, Christof Arnosti > > wrote:
>>
>> Hi Dirk,
>>
>> I did the integration of the Icon HD VID/PID pair, so if the testing
>> is successful I think there is nothing left for me to do before a merge.
>>
>
> I will play with this in a couple of hours and most likely merge your
> changes.
I'm looking forward to leave my laptop at home for my next diving
holiday! :-)
>
>> Someone just tested with an Mares Nemo Wide (Serial < 5), and it
>> did also work.
>>
>
> Excellent.
>
>> Just for clarification about the possible UI changes (now that I'm
>> more awake again), I would envision a workflow like this:
>> - When opening the divecomputer-screen, or pressing the refresh
>> button ("Neu Scannen" in german), get all UsbDevices by issuing
>> UsbManager.getDeviceList(). Use these to populate the connection
>> ("Verbindung") list. (Only show the entries with specified
>> driver-class when this is activated in the settings). I think there
>> has to be done some work in the bt-discovery part so that these two
>> mechanisms can work together.
>>
>
> I'm not sure what you mean by only showing the entries with a
> specified driver class. I thought the driver class is something that
> you would select in that Connection drop down as an alternative to the
> found devices.
> My guess is that on the vast, vast majority of Android devices you
> will only ever get one USB device. Maybe if someone uses a hub for
> some reason (maybe to power the phone while reading dives?) one might
> see more, but in general that would surprise me.
> So we should optimize the user experience for the common case. Which
> means to try and identify the one USB serial device that is connected.
>>
>> - When a device from the connection list is selected, maybe try to
>> guess Vendor / Model by data provided in the UsbDevice-Object. There
>> is already some code in QMLManager::showDownloadPage. I'm not sure
>> how much there can be done since it seems that a lot of devices use
>> the same PID/VIDs.
>>
>
> Correct - I played with that back when working on the Intent code and
> while there are a couple you can explicitly identify, for most that is
> not possible
>
>> - When the download-button is pressed, the UsbDevice-Object of the
>> selected connection (and if selected the name of the driver-class)
>> should be passed to serial_android_usb_open. From there on I can do
>> the work.
>>
>
> So again, you are suggesting to have a second (or actually, fourth?)
> drop down with a driver class?
No, I would keep the existing "connection" dropdown.

My Idea for populating the list would be this:

- Have a setting in the application settings like "Allow usb-serial
driver selection". (since in most cases the driver can be automatically
detected - as you said, most DCs have known PID/VID pairs).
- In the device-dropdown display all found USB devices (as you said,
most likely it's just one).
-> If the Driver-Selection setting is not enabled, just show something
like "Silicon Labs CP2102" per USB device.
-> If the Driver-Selection setting is enabled, show multiple entries per
driver, something like "Silicon Labs CP2102 (autodetect driver)",
"Silicon Labs CP2102 (FTDI)", "Silicon Labs CP2102 (CP21xx)" etc., for
all the driver classes.

Does this make more sense?

>
>> There would probably also have to be done some changes when receiving
>> the USB_DEVICE_ATTACHED intent so that the correct entry of the list
>> is preselected.
>>
>
> I believe so.
>
> /D
Best regards
Christof
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Dirk,

I did the integration of the Icon HD VID/PID pair, so if the testing is
successful I think there is nothing left for me to do before a merge.

Someone just tested with an Mares Nemo Wide (Serial < 5), and it did
also work.

Just for clarification about the possible UI changes (now that I'm more
awake again), I would envision a workflow like this:
- When opening the divecomputer-screen, or pressing the refresh button
("Neu Scannen" in german), get all UsbDevices by issuing
UsbManager.getDeviceList(). Use these to populate the connection
("Verbindung") list. (Only show the entries with specified driver-class
when this is activated in the settings). I think there has to be done
some work in the bt-discovery part so that these two mechanisms can work
together.
- When a device from the connection list is selected, maybe try to guess
Vendor / Model by data provided in the UsbDevice-Object. There is
already some code in QMLManager::showDownloadPage. I'm not sure how much
there can be done since it seems that a lot of devices use the same
PID/VIDs.
- When the download-button is pressed, the UsbDevice-Object of the
selected connection (and if selected the name of the driver-class)
should be passed to serial_android_usb_open. From there on I can do the
work.

There would probably also have to be done some changes when receiving
the USB_DEVICE_ATTACHED intent so that the correct entry of the list is
preselected.

Best regards
Christof

On 07.03.20 02:11, Dirk Hohndel via subsurface wrote:
>
>
>> On Mar 6, 2020, at 5:03 PM, Christof Arnosti > > wrote:
>>> And here you are losing me again :-)
>>> Are you suggesting that we could walk through the list of devices
>>> and try to populate the dropdowns on the download page accordingly?
>>> That sounds like a great idea.
>> Yes, that's exactly what I tried to suggest. Thanks for putting it in
>> understandable words, it's getting late here.
>
> It is indeed.
>
 I didn't consciously check for devices not entered in the
 device_filter.xml, but I entered "my" PID/VID pair quite late in
 the development cycle. I also have seen and used the "ask
 permission" popup which happens when a device not in
 device_filter.xml is used. I will test this tomorrow by removing
 "my" entry from the device_filter.xml.

>>>
>>> Excellent. Should I wait for further updates from you before merging
>>> the current code?
>>
>> Hmm... I'd propose that I add the CdcAcm-driver for the Icon HD
>> VID/PID (if this works then all the PID/VIDs from
>> libdivecomputer.org/drivers.html
>>  are be supported! :-D)
>> tomorrow, and that you then merge the code if everything else is fine.
>>
>
> That sounds excellent to me. I can test this and then merge the PR.
>
>> Work on the UI could be done in a separate branch, and I'm happy to
>> help on the driver side.
>>
>
> That was my plan. I'll do the UI / integration work and we'll figure
> out what's needed on the driver side to make this work.
>
> So exciting!
>
> /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 Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Am 07.03.20 um 00:30 schrieb Dirk Hohndel via subsurface:
>
>> On Mar 6, 2020, at 3:23 PM, Christof Arnosti > > wrote:

 There is a driver with CdcAcmSerialDriver in usb-serial-for-android!

 That's exactly the use case I had in mind when I proposed
 driverclass-selection in the UI ;-)

>>>
>>> I understand - but Subsurface-mobile would never ever get access to
>>> this if we don't claim the PID/VID correct?
>>> That's been my point here... even if you add that driverclass... how
>>> would Subsurface-mobile get access to that device in the first place?
>>> Maybe I'm just misunderstanding how this is supposed to work.
>>
>> If I understand correctly, the device_filter.xml is only necessary to
>> get the popup which then leads to the download-page.
>>
>> In the Java code, all devices known to UsbManager are compared by
>> PID/VID by UsbSerialProber (from usb-serial-for-android). When
>> there's a match there is a check if we have permission to use this
>> device, and if not the permission is requested. Then the device is used.
>>
>
> Ahh, that's the part that I didn't realize. I thought you never get to
> see devices that you haven't registered. In that case, yes, indeed
> your idea to have those generic diver-classes available does make
> sense. I'd still hide them in general as this should be the exception
> (and I'd add some feature that makes it easy for people to send us
> email with the necessary information so we can add the VID/PID for them).
Perfect!
>
>> If we do the UsbManager-stuff beforehand to populate the device-list
>> (and then pass the selected usb device to Java android_serial_open)
>> we don't need the UsbSerialProber to check the attached device, but
>> only to find the correct driver class. If the driver class is also
>> passed to android_serial_open we can leave out the whole
>> UsbSerialProber-Stuff and directly instantiate the driver class with
>> the passed usb device. With all this it's still possible to check and
>> request for permission to access the device at runtime.
>>
>
> And here you are losing me again :-)
> Are you suggesting that we could walk through the list of devices and
> try to populate the dropdowns on the download page accordingly? That
> sounds like a great idea.
Yes, that's exactly what I tried to suggest. Thanks for putting it in
understandable words, it's getting late here.
>  
>>
>> I didn't consciously check for devices not entered in the
>> device_filter.xml, but I entered "my" PID/VID pair quite late in the
>> development cycle. I also have seen and used the "ask permission"
>> popup which happens when a device not in device_filter.xml is used. I
>> will test this tomorrow by removing "my" entry from the
>> device_filter.xml.
>>
>
> Excellent. Should I wait for further updates from you before merging
> the current code?

Hmm... I'd propose that I add the CdcAcm-driver for the Icon HD VID/PID
(if this works then all the PID/VIDs from
libdivecomputer.org/drivers.html are be supported! :-D) tomorrow, and
that you then merge the code if everything else is fine.

Work on the UI could be done in a separate branch, and I'm happy to help
on the driver side.

>
> /D
Best regards
Christof
>
>
> ___
> 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 Mobile: Adding mares USB (cp210x) support; how to proceed

[Christof Arnosti via subsurface]

Hi Dirk,

Am 06.03.20 um 23:32 schrieb Dirk Hohndel:
> (oops. I dropped the mailing list by mistake)
>
>> On Mar 6, 2020, at 2:12 PM, Christof Arnosti > > wrote:
>> Am 06.03.20 um 22:59 schrieb Dirk Hohndel:
>>>
>>>
 On Mar 6, 2020, at 1:54 PM, Christof Arnosti >>> > wrote:
> No popup at all as no one has that PID/VID registered. I can simply
> add the PID/VID and see if it works. I'll play with that later today.

 Also try to register the different driver classes in
 https://github.com/charno/subsurface/blob/android-serial-clean/android-mobile/src/org/subsurfacedivelog/mobile/AndroidSerial.java#L92.
 The classes can be found at
 https://github.com/mik3y/usb-serial-for-android/tree/master/usbSerialForAndroid/src/main/java/com/hoho/android/usbserial/driver.
>>>
>>> ok
>>>
>> Can you maybe plug your Mares Icon HD into a computer and give me
>> some
>> lsusb and dmesg-output so I can try to guess which vid/pid and
>> driver is
>> used?
> VID/PID is 0x/0x0005:
>
> 03-06 13:39:52.669  1342  1869 D UsbHostManager: USB device
> attached: vidpid :0005 mfg/product/ver/serial
> SERUSB/USBSerial/1.00/01234567 hasAudio/HID/Storage: false/false/false
> 03-06 13:39:52.673  1342  1869 D UsbDeviceDescriptor:   1 configs
> 03-06 13:39:52.674  1342  1869 D UsbHostManager: Added device
> UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=65535,mProductId=5,mClass=2,mSubclass=0,mProtocol=0,mManufacturerName=SERUSB,mProductName=USBSerial,mVersion=1.00,mSerialNumberReader=com.android.server.usb.UsbSerialReader@9967699,mConfigurations=[
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbConfiguration[mId=2,mName=null,mAttributes=192,mMaxPower=250,mInterfaces=[
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbInterface[mId=0,mAlternateSetting=0,mName=null,mClass=2,mSubclass=2,mProtocol=0,mEndpoints=[
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbEndpoint[mAddress=130,mAttributes=3,mMaxPacketSize=8,mInterval=10]]
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbInterface[mId=1,mAlternateSetting=0,mName=null,mClass=10,mSubclass=0,mProtocol=0,mEndpoints=[
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbEndpoint[mAddress=1,mAttributes=2,mMaxPacketSize=64,mInterval=0]
> 03-06 13:39:52.674  1342  1869 D UsbHostManager:
> UsbEndpoint[mAddress=129,mAttributes=2,mMaxPacketSize=64,mInterval=0
>
>
> (this is adb logcat over tcp of plugging the Icon HD into my
> Android phone)
 If you have a linux computer at hand I would be interested which driver
 is used by the kernel. This might give some insight if it's implemented
 in usb-serial-for-android and just not registred, or if the driver is
 missing.
>>>
>>> [2382095.960170] usb 2-1.2: new full-speed USB device number 4 using
>>> ehci-pci
>>> [2382096.041381] usb 2-1.2: New USB device found, idVendor=,
>>> idProduct=0005, bcdDevice= 1.00
>>> [2382096.041388] usb 2-1.2: New USB device strings: Mfr=1,
>>> Product=2, SerialNumber=3
>>> [2382096.041392] usb 2-1.2: Product: USBSerial
>>> [2382096.041395] usb 2-1.2: Manufacturer: SERUSB
>>> [2382096.041398] usb 2-1.2: SerialNumber: 01234567
>>> [2382096.089122] cdc_acm 2-1.2:2.0: ttyACM0: USB ACM device
>>> [2382096.089748] usbcore: registered new interface driver cdc_acm
>>> [2382096.089750] cdc_acm: USB Abstract Control Model driver for USB
>>> modems and ISDN adapters
>>>
>>> This is from a Linux laptop
>>
>> There is a driver with CdcAcmSerialDriver in usb-serial-for-android!
>>
>> That's exactly the use case I had in mind when I proposed
>> driverclass-selection in the UI ;-)
>>
>
> I understand - but Subsurface-mobile would never ever get access to
> this if we don't claim the PID/VID correct?
> That's been my point here... even if you add that driverclass... how
> would Subsurface-mobile get access to that device in the first place?
> Maybe I'm just misunderstanding how this is supposed to work.

If I understand correctly, the device_filter.xml is only necessary to
get the popup which then leads to the download-page.

In the Java code, all devices known to UsbManager are compared by
PID/VID by UsbSerialProber (from usb-serial-for-android). When there's a
match there is a check if we have permission to use this device, and if
not the permission is requested. Then the device is used.

If we do the UsbManager-stuff beforehand to populate the device-list
(and then pass the selecte usb device to Java android_serial_open) we
don't need the UsbSerialProber to check the attached device, but only to
find the correct driver class. If the driver class is also passed to
android_serial_open we can leave out the whole UsbSerialProber-Stuff and
directly instantiate the driver class with the passed usb device. With
all this it's still possible to check and request for permission to
access the device