Re: latest Subsurface-mobile with latest Kirigami has no Icons

[Benjamin]

The icons have vanished here too :) other than that, I can't see any
scrolling problems on my archaic Galaxy S5 running Android 6.0.1.

Benjamin

On Mon, 16 Apr 2018, 06:37 Dirk Hohndel,  wrote:

> Hi Marco,
>
> I updated Subsurface-mobile to the latest Kirigami - which helped fix a
> serious ListView scrolling issue...
> But it also made all the icons in Subsurface-mobile disappear.
> Interestingly current Kirigami master removed src/Icon.qml a few days ago
> - even though thats still referenced in src/qmldir (and there are still
> references to Kirigami.Icon in other files) - so I'm a bit confused about
> the current state of upstream Kirigami, I guess :-(
>
> I'd love some help to figure out what's going on there :-)
>
> 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

Re: A few changes to the QML UI

[Miika Turkia]

On Sun, Apr 15, 2018 at 10:20 PM, Dirk Hohndel  wrote:

> The latest build that I pushed this morning seems to behave much better,
> even on my old phone where I could "kind of" reproduce what you describe.
>
> Did you have a chance to try it?
>

Unfortunately I still have jerkynes when scrolling on iPhone 5S. The log
seems to have a couple of "QObject: startTimer: Timers cannot be started
from another thread" messages. No idea if this is related or not. I think
the scrolling has improved quite a bit but still very painful on this
device.

Scrolling the debug log works fine when going to one direction, but when
switching it has a brief moment of immobility. The location at the top of
the debug log is either shown or hidden when switching direction and this
might be related to the problem. Scrolling pauses once during the
transition and once it is completed the scrolling to this direction works
fine.

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

latest Subsurface-mobile with latest Kirigami has no Icons

[Dirk Hohndel]

Hi Marco,

I updated Subsurface-mobile to the latest Kirigami - which helped fix a serious 
ListView scrolling issue...
But it also made all the icons in Subsurface-mobile disappear.
Interestingly current Kirigami master removed src/Icon.qml a few days ago - 
even though thats still referenced in src/qmldir (and there are still 
references to Kirigami.Icon in other files) - so I'm a bit confused about the 
current state of upstream Kirigami, I guess :-(

I'd love some help to figure out what's going on there :-)

Thanks

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

Re: A few changes to the QML UI

[Dirk Hohndel]

> On Apr 15, 2018, at 1:24 PM, Linus Torvalds  
> wrote:
> 
> On Sun, Apr 15, 2018, 13:19 Dirk Hohndel  > wrote:
> 
> If you feel strongly about being able to have multiple trips open that should 
> not be hard. 
> 
> I don't feel strongly at all. I think it was more of a reaction from "this is 
> different from what I expected from the desktop version".
> 
> So as far as I'm concerned, leave it as is until somebody comes up with a 
> good reason to have multiple trips open.

Cool, will do.

BTW, I also fixed the "no SAC rate shown" bug that we noticed last weekend.
This now also works as expected - after you download, when you update the 
cylinder information, the derived info is updated as well.

/D

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

Re: A few changes to the QML UI

[Linus Torvalds]

On Sun, Apr 15, 2018, 13:19 Dirk Hohndel  wrote:

>
> If you feel strongly about being able to have multiple trips open that
> should not be hard.
>

I don't feel strongly at all. I think it was more of a reaction from "this
is different from what I expected from the desktop version".

The mobile behavior might indeed be better for the small screen.

The only issue I see is if you would want to compare dives in two different
trips, but I'm not sure that's an actual issue at all. The mobile version
doesn't show the kinds of things that I normally look at in the dive list
anyway (ie SAC rate etc) so you have to go into the dives for that anyway.

So as far as I'm concerned, leave it as is until somebody comes up with a
good reason to have multiple trips open.

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

Re: A few changes to the QML UI

[Dirk Hohndel]

Sorry, on the phone.
That was an intentional design decision to simplify things for the mobile UI.
If you feel strongly about being able to have multiple trips open that should 
not be hard. I somehow thought this was better for the small screen (as the 
goal was to make it easier for people to get a quick overview)
What do you think?

/D

On April 15, 2018 1:00:22 PM PDT, Linus Torvalds 
 wrote:
>On Sun, Apr 15, 2018, 12:53 Linus Torvalds
>
>wrote:
>
>>
>> I'll go check on my tablet too, but I'm assuming it's fixed there as
>well.
>> If you hear nothing, assume it's all good.
>>
>
>All good there too.
>
>But now that I can actually scroll around and test, I notice that I can
>only have at most one trip expanded.
>
>That works, and maybe it's the simplest model, but my UI expectations
>were
>that I can expand and collapse trips independently of each other.
>
>So not sure this is a problem or not. Perhaps more of a "that wasn't
>what I
>expected".
>
>Still very lovely, and makes it much easier to find a dive.
>
>  Linus

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

Re: A few changes to the QML UI

[Linus Torvalds]

On Sun, Apr 15, 2018, 12:53 Linus Torvalds 
wrote:

>
> I'll go check on my tablet too, but I'm assuming it's fixed there as well.
> If you hear nothing, assume it's all good.
>

All good there too.

But now that I can actually scroll around and test, I notice that I can
only have at most one trip expanded.

That works, and maybe it's the simplest model, but my UI expectations were
that I can expand and collapse trips independently of each other.

So not sure this is a problem or not. Perhaps more of a "that wasn't what I
expected".

Still very lovely, and makes it much easier to find a dive.

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

Re: Change water type

[tormento]

Awesome explanation and great diving computer knowledge, thanks!

I asked as I have interest in physiology and I do my best to know how
things work under the water and inside body.

Your reasons are more than good for the average user.

Il giorno dom 15 apr 2018 alle 20:55 Linus Torvalds <
torva...@linux-foundation.org> ha scritto:

> On Sun, Apr 15, 2018 at 12:07 AM, tormento  wrote:
> >
> > Henry's Law is based on (partial) pressures and not depths. I dunno how
> > diving computer talks to subsurface. If giving depths instead of
> pressures
> > it would be a pity.
>
> Almost all dive computers only give depth.
>
> Some give salinity, some don't. And some only give the flag (sweet vs
> salt) rather than the salinity value they actually use to calculate
> depth.
>
> In other words: do not EVER play games with salinity. You don't know
> what it was, and you will get it wrong.
>
> The whole notion of "user should set salinity" is broken garbage. A
> dive computer shouldn't even have that setting. Because that setting
> cannot possibly matter, because the only thing that matters - and the
> only thing the dive computer measures - is actual pressure, and all
> you can do with salinity is make a "correction" to the depth
> calculation that you can get wrong.
>
> So in my not-so-humble opinion, a dive computer should always just
> show depth as "salt water equivalent depth", with no way to screw up,
> and no complications. If you dive in a lake, you'll get the depth
> wrong by a few percent, but nobody cares since it's not a really
> meaningful value anyway, it's just a user-friendly approximation for
> the value that matters: pressure.
>
> Giving the users just the absolute ambient water pressure migth be
> *technically* the right thing to do, but it's such a user-hostile
> datapoint that it's completely wrongheaded. It only moves the
> possibility for error into another place (ie the UI during diving, or
> the UI during later logging).
>
> So what you should do is:
>
>  - set your dive computer to salt water (if it has a setting), and
> forget about it. Don't ever touch the setting, all it can do is cause
> confusion.
>
>  - think of "depth" as "equivalent depth in salt water" and be happy
>
>  - mark your lake dives as such in the dive log tags if you care, the
> same way you mark boat dives and buddy names.
>
> The sweet-vs-salt water thing has absolutely zero meaning outside of
> informing yourself, and has exactly the same relevance as the name of
> your dive buddy: nice to know, but not relevant for any other meaning.
> Don't give it any relevance that will only confuse you and get things
> wrong.
>
> Because anything else is just a disaster waiting to happen. You *will*
> get it wrong, and you will only confuse yourself. Trying to correct
> things later is just going to make things worse.
>
> Linus
>
> PS. Yes, there are dive computers that don't report depth at all, and
> report the actual hydrostatic pressure that their sensor gives. Before
> you say "that's what everybody should do", let me just say that (a)
> they are a tiny minority and (b) even they aren't consistent (ie is it
> absolute pressure, or relative to surface pressure?)
>
> So subsurface logs what the vast majority of dive computers give you:
> depth. In fact, we don't even see the pressure, because the conversion
> will have been done by libdivecomputer. So as far as we're concerned,
> no dive computer gives us pressure, but technically you can get the
> water pressure from the Atomic Aquatics Cobatl, from the
> Heinrichs-Weicamp OSTC and from the Reefnet Sensus Ultra. (That last
> one isn't actually a dive computer, it's just a data logging device.
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: A few changes to the QML UI

[Dirk Hohndel]

The latest build that I pushed this morning seems to behave much better, even 
on my old phone where I could "kind of" reproduce what you describe.

Did you have a chance to try it?

/D

On April 14, 2018 10:11:31 PM PDT, Linus Torvalds 
 wrote:
>On Sat, Apr 14, 2018, 21:08 Linus Torvalds
>
>wrote:
>
>>
>> It's very clear, and happens both with all trips collapsed and with
>one or
>> more trips exposed. I can scroll down once, but when I try to scroll
>> further, at first nothing happens at all, then it resets to an
>earlier
>> state (maybe back to the top) and then it scrolls down some more.
>>
>
>Ok, so there is a pattern to the oddity.
>
>I tried to move my finger very slowly and keep track of where my finger
>was
>and which entry I was touching.
>
>I may not be great at explaining the behavior I see, but imagine that
>you
>have all trips collapsed, and the first scroll event is you touching a
>trip
>right in the middle of the screen, and slowly moving your finger up.
>Everything works fine.
>
>It at least *almost* fine. I think there is an off-by-one error, where
>when
>I put my finger down tp before I move it, the dive list jumps by one
>entry.
>So there is a small jerk event happening even there, but it's almost
>unnoticeable. The scrolling itself is fairly smooth once I start moving
>my
>finger.
>
>Then, release the finger, and start the next scroll event lower down
>(say,
>three quarters of to the bottom), and moved your finger up to scroll.
>
>During that second scroll event, *nothing* happens in the screen for me
>at
>first, until my finger hits the point where I started the *first*
>scroll
>(so I moved my finger from 3/4 down the screen up to the halfway point
>without anything moving at all). But when I hit that point where I
>started
>my previous scroll, the dive log screen resets to where it was the
>*last*
>scroll event, and then starts scrolling with my finger again.
>
>So I never and up making any actual progress, and it feels really jerky
>because part of the time the screen doesn't react to the finger at all,
>and
>then when you pass a certain point it jumps and starts reacting again,
>just
>at the wrong place.
>
>So there seems to be some "screen offset" thing going on, with some
>history.
>
>Except *occasionally* the second scroll event works fine. So I can make
>some progress every once in a while. I didn't figure out the pattern
>for
>that, though.
>
>   Linus
>
>>

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

Re: Change water type

[Linus Torvalds]

On Sun, Apr 15, 2018 at 12:07 AM, tormento  wrote:
>
> Henry's Law is based on (partial) pressures and not depths. I dunno how
> diving computer talks to subsurface. If giving depths instead of pressures
> it would be a pity.

Almost all dive computers only give depth.

Some give salinity, some don't. And some only give the flag (sweet vs
salt) rather than the salinity value they actually use to calculate
depth.

In other words: do not EVER play games with salinity. You don't know
what it was, and you will get it wrong.

The whole notion of "user should set salinity" is broken garbage. A
dive computer shouldn't even have that setting. Because that setting
cannot possibly matter, because the only thing that matters - and the
only thing the dive computer measures - is actual pressure, and all
you can do with salinity is make a "correction" to the depth
calculation that you can get wrong.

So in my not-so-humble opinion, a dive computer should always just
show depth as "salt water equivalent depth", with no way to screw up,
and no complications. If you dive in a lake, you'll get the depth
wrong by a few percent, but nobody cares since it's not a really
meaningful value anyway, it's just a user-friendly approximation for
the value that matters: pressure.

Giving the users just the absolute ambient water pressure migth be
*technically* the right thing to do, but it's such a user-hostile
datapoint that it's completely wrongheaded. It only moves the
possibility for error into another place (ie the UI during diving, or
the UI during later logging).

So what you should do is:

 - set your dive computer to salt water (if it has a setting), and
forget about it. Don't ever touch the setting, all it can do is cause
confusion.

 - think of "depth" as "equivalent depth in salt water" and be happy

 - mark your lake dives as such in the dive log tags if you care, the
same way you mark boat dives and buddy names.

The sweet-vs-salt water thing has absolutely zero meaning outside of
informing yourself, and has exactly the same relevance as the name of
your dive buddy: nice to know, but not relevant for any other meaning.
Don't give it any relevance that will only confuse you and get things
wrong.

Because anything else is just a disaster waiting to happen. You *will*
get it wrong, and you will only confuse yourself. Trying to correct
things later is just going to make things worse.

Linus

PS. Yes, there are dive computers that don't report depth at all, and
report the actual hydrostatic pressure that their sensor gives. Before
you say "that's what everybody should do", let me just say that (a)
they are a tiny minority and (b) even they aren't consistent (ie is it
absolute pressure, or relative to surface pressure?)

So subsurface logs what the vast majority of dive computers give you:
depth. In fact, we don't even see the pressure, because the conversion
will have been done by libdivecomputer. So as far as we're concerned,
no dive computer gives us pressure, but technically you can get the
water pressure from the Atomic Aquatics Cobatl, from the
Heinrichs-Weicamp OSTC and from the Reefnet Sensus Ultra. (That last
one isn't actually a dive computer, it's just a data logging device.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

ftdi download broken ?

[Salvador Cuñat]

Good morning.

I've been out of the water for a while, and re-took diving this month.
I've found that I can't do ftdi download both on android and on desktop. As
usual, on desktop, regular USB download via /dev/ttyUSB0 works just fine.
Past year (october?) ftdi download worked well for me on desktop and
android.

Using a H OSTC 2N.

On Android, there is nothing interesting in the log, but on desktop I get
this:

  1 Subsurface: v4.7.8, built with libdivecomputer
v0.7.0-devel-Subsurface-branch (d02f1c3cdcc6a04d085538578d872ec6e3282382)
  2 INFO: Open: name=ftdi
  3 ERROR: No existe el fichero o el directorio (2) [in
../../src/serial_posix.c:299 (dc_serial_open)]
  4 ERROR: Failed to open the serial port. [in ../../src/hw_ostc.c:148
(hw_ostc_device_open)]

And, in console we can see:

Starting download from  ftdi
Starting the thread 0
INFO: dc_deveice_open error value of -4

The error seems to be:

common.h:DC_STATUS_NODEVICE = -4,

I thought it could be a permission issue, but I get the same even running
as root.

BTW I'm using the appimage, as I'm unable to build the map plugin (debian
has moved recently to Qt5 10.1 and something else seems broken here).

Best regards.

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

Re: Change water type

[tormento]

Good idea, that's what I did. I discovery, with some disappointment, that
the file saves depths and not pressures, giving head scratching about real
influence of set salinity to program and calculations.

Henry's Law is based on (partial) pressures and not depths. I dunno how
diving computer talks to subsurface. If giving depths instead of pressures
it would be a pity.

A pressure is a direct measurement and can be post diving corrected with
salinity to correct depth, even when the computer was wrongly set.

In the saved file I saw a salinity of 1025 g/l and it's ok for oceanic
water but completely wrong for closed seas and tropical ones (1033-1044
g/l).

If possibile I suggest programmers to introduce interface to set standard
salinity AND the possibility to modify single dive ones and to clarify if
it has some impact to calculus of real depth and pressure.

Moreover, if the diving computer gives you both pressure and depth, for
god's sake, get pressure values and THEN convert to depth.

In a second moment we should talk about apparent depth on mountain
divings...

2018-04-14 14:55 GMT+02:00 Salvador Cuñat :

> Good afternoon.
>
> On Sat, Apr 14, 2018 at 12:09:38PM +, tormento wrote:
> >
> > A way to fix salinity would be welcome, even hex editing configuration
> file.
> >
>
> I don't think there is a direct or easy way to change random values on a
> cloud
> stored divelog.
>
> A workaround for it could be  (on desktop subsurface):
>
> 1.- Sync with cloud.
> 2.- Save the log to a local .xml or .ssrf file
> 3.- Edit the values:
> a.- manually with your preferred editor
> b.- on linux a sed command would do the job
> 4.- Open the modified file in subsurface
> 5.- Double or triple check the changes
> 6.- Select "Save to cloud storage"
>
> This should do the trick.  As a bonus you will have a local backup
> file which can be useful if anything goes wild in the future.
>
> Best regards.
>
> Salva
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface