Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

Hm... nailed it
Very strange.
I used to send photos to my pc and vm by attaching them to a mail from me
on the phone to me on the pc/vm and downloading from attachments. I am
surprised it worked for you Berthol.d... maine you are not using gmail
webmail as a email client. Some people who implement these things have lots
of time to thing about these gimmicks...
Downloading from gmail webmail seems to strip exif gps data .
I connected the phone to my pc directly and transferred the file >>> gps
data is there , subsurface adds the dive location with gps .

Stupid something on gmail side.

So after all feature on subsurface works as expected on win and linux
fedora ..

Keep safe,
Theodor

On Sat, May 9, 2020 at 1:15 AM Berthold Stoeger 
wrote:

> On Freitag, 8. Mai 2020 23:15:19 CEST Linus Torvalds via subsurface wrote:
> > Have you tried with the test picture?
> >
> > Maybe the GPS data in your own picture has some other format
>
> As noted upthread, Theodor sent me the picture in question and it worked
> just
> fine for me, so that shouldn't be the problem.
>
> (Side note: I'm currently travelling and therefore slow with emails.)
>
> Berthold
>
>
>

-- 

Cu stima/Best regards/Mit freundlichen Grüßen,

Chirana-Gheorghita Eugeniu-Theodor
Bucharest, Romania

e-mail : off...@adaptcom.ro
mobile: 0743 698721
0747 447675
SSI diver ID: 1118289
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Berthold Stoeger via subsurface]

On Freitag, 8. Mai 2020 23:15:19 CEST Linus Torvalds via subsurface wrote:
> Have you tried with the test picture?
> 
> Maybe the GPS data in your own picture has some other format

As noted upthread, Theodor sent me the picture in question and it worked just 
fine for me, so that shouldn't be the problem.

(Side note: I'm currently travelling and therefore slow with emails.)
 
Berthold


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

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

Now I am really confused.
exiftool on windows , for my pic does not show gps data. exiftool on
android shows that I have gps data.
Weird. Maibe the exif data is stored in another format

On Sat, May 9, 2020 at 12:55 AM Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> Hmmm.
> I now look with exiftool at the 2 pics. mine and wreck.jpg. It seems that
> th estupid droid keeps the location data in other place not in the exif
> info.
> I will have to see how I take pics with exif gps data.
>
> Damn.
>
> On Sat, May 9, 2020 at 12:32 AM Chirana Gheorghita Eugeniu Theodor <
> off...@adaptcom.ro> wrote:
>
>> same thing if i name the dive site and try to apply gos fixes. app just
>> freezes. speaking of droid version .80 now.
>>
>> On Sat, May 9, 2020, 00:30 Chirana Gheorghita Eugeniu Theodor <
>> off...@adaptcom.ro> wrote:
>>
>>> H.
>>> But should we rely only on a test pic? I am testing with a pic that
>>> is taken like every user does.. with a phone. I will test also with the
>>> test pic.
>>>
>>> Also another one:
>>>
>>> I start location on my phone
>>> Allow subsurdace rights to use location
>>> Start app
>>> Start gos data collecting
>>> add a new dive
>>> save.
>>> exit app and reopen
>>> look at gps fixes and I have one
>>> go to apply gps fixes and app completly feezez. In the log i see the
>>> entry where it starts the attempt to apply gos fixes.
>>> force app close
>>> reopen app, no gps fixes
>>>
>>>
>>>
>>> On Sat, May 9, 2020, 00:15 Linus Torvalds 
>>> wrote:
>>>
 Have you tried with the test picture?

 Maybe the GPS data in your own picture has some other format that
 subsurface doesn't then parse right?

   Linus

 On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
 subsurface  wrote:

> and I use my own pic which has gos data
>

>
> --
> 
> Cu stima/Best regards/Mit freundlichen Grüßen,
>
> Chirana-Gheorghita Eugeniu-Theodor
> Bucharest, Romania
>
> e-mail : off...@adaptcom.ro
> mobile: 0743 698721
> 0747 447675
> SSI diver ID: 1118289
>


-- 

Cu stima/Best regards/Mit freundlichen Grüßen,

Chirana-Gheorghita Eugeniu-Theodor
Bucharest, Romania

e-mail : off...@adaptcom.ro
mobile: 0743 698721
0747 447675
SSI diver ID: 1118289
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

Hmmm.
I now look with exiftool at the 2 pics. mine and wreck.jpg. It seems that
th estupid droid keeps the location data in other place not in the exif
info.
I will have to see how I take pics with exif gps data.

Damn.

On Sat, May 9, 2020 at 12:32 AM Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> same thing if i name the dive site and try to apply gos fixes. app just
> freezes. speaking of droid version .80 now.
>
> On Sat, May 9, 2020, 00:30 Chirana Gheorghita Eugeniu Theodor <
> off...@adaptcom.ro> wrote:
>
>> H.
>> But should we rely only on a test pic? I am testing with a pic that
>> is taken like every user does.. with a phone. I will test also with the
>> test pic.
>>
>> Also another one:
>>
>> I start location on my phone
>> Allow subsurdace rights to use location
>> Start app
>> Start gos data collecting
>> add a new dive
>> save.
>> exit app and reopen
>> look at gps fixes and I have one
>> go to apply gps fixes and app completly feezez. In the log i see the
>> entry where it starts the attempt to apply gos fixes.
>> force app close
>> reopen app, no gps fixes
>>
>>
>>
>> On Sat, May 9, 2020, 00:15 Linus Torvalds 
>> wrote:
>>
>>> Have you tried with the test picture?
>>>
>>> Maybe the GPS data in your own picture has some other format that
>>> subsurface doesn't then parse right?
>>>
>>>   Linus
>>>
>>> On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
>>> subsurface  wrote:
>>>
 and I use my own pic which has gos data

>>>

-- 

Cu stima/Best regards/Mit freundlichen Grüßen,

Chirana-Gheorghita Eugeniu-Theodor
Bucharest, Romania

e-mail : off...@adaptcom.ro
mobile: 0743 698721
0747 447675
SSI diver ID: 1118289
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

same thing if i name the dive site and try to apply gos fixes. app just
freezes. speaking of droid version .80 now.

On Sat, May 9, 2020, 00:30 Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> H.
> But should we rely only on a test pic? I am testing with a pic that is
> taken like every user does.. with a phone. I will test also with the test
> pic.
>
> Also another one:
>
> I start location on my phone
> Allow subsurdace rights to use location
> Start app
> Start gos data collecting
> add a new dive
> save.
> exit app and reopen
> look at gps fixes and I have one
> go to apply gps fixes and app completly feezez. In the log i see the entry
> where it starts the attempt to apply gos fixes.
> force app close
> reopen app, no gps fixes
>
>
>
> On Sat, May 9, 2020, 00:15 Linus Torvalds 
> wrote:
>
>> Have you tried with the test picture?
>>
>> Maybe the GPS data in your own picture has some other format that
>> subsurface doesn't then parse right?
>>
>>   Linus
>>
>> On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
>> subsurface  wrote:
>>
>>> and I use my own pic which has gos data
>>>
>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

H.
But should we rely only on a test pic? I am testing with a pic that is
taken like every user does.. with a phone. I will test also with the test
pic.

Also another one:

I start location on my phone
Allow subsurdace rights to use location
Start app
Start gos data collecting
add a new dive
save.
exit app and reopen
look at gps fixes and I have one
go to apply gps fixes and app completly feezez. In the log i see the entry
where it starts the attempt to apply gos fixes.
force app close
reopen app, no gps fixes



On Sat, May 9, 2020, 00:15 Linus Torvalds 
wrote:

> Have you tried with the test picture?
>
> Maybe the GPS data in your own picture has some other format that
> subsurface doesn't then parse right?
>
>   Linus
>
> On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
> subsurface  wrote:
>
>> and I use my own pic which has gos data
>>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Linus Torvalds via subsurface]

Have you tried with the test picture?

Maybe the GPS data in your own picture has some other format that
subsurface doesn't then parse right?

  Linus

On Fri, May 8, 2020, 14:05 Chirana Gheorghita Eugeniu Theodor via
subsurface  wrote:

> and I use my own pic which has gos data
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

and I use my own pic which has gos data

On Sat, May 9, 2020, 00:01 Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> Sorry to be a party breaker but here it goes:
> same tests done on windows and linux fedora with subsurface 4.9.4.80:
>
> - create new dive, adjust time so I am in 30 mins after the dive
> - save
> - exit app
> - open app , add picture >> no new dive site, no gps
> - exit app
> -open app > still no dive site , nor added to the dive nor in the general
> dive sites tab
> - delete dive
>
> second test:
>
> - create new dive, adjust time so I am in 30 mins after the dives
> - name a test dive site for the dive with no gps
> - save
> - exit app
> - open app , add picture >> no gps data added to the test dive site
> - exit app
> -open app > still no gps data on the dive site
> - delete dive
>
> third test on linux only for the other issue:
>
> - create new dive site
> - edit in dive planner and save , description get's populated with the
> dive plan
> - save , exit app
> - open app and the dreaded error is there:
> git-load: string marker after running out of strings ('description')
>
>
>
>
>
>
>
> On Fri, May 8, 2020 at 10:50 PM Dirk Hohndel via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
>> On Fri, 2020-05-08 at 21:22 +0200, Willem Ferguson via subsurface
>> wrote:
>> >
>> > Something I missed. If, for a dive, I have the dive location as a
>> > named
>> > dive site with coordinates and then attach a photo with other
>> > coordinates, does anything happen? I tried this on my Ubuntu box and
>> > I
>> > could not see anything happening (correctly, I would think). The
>> > photo
>> > appeared in the Media tab for that dive and I could not find any new
>> > location in dive site list.
>>
>> That's the expected behavior. If your dive site has a valid GPS fix,
>> adding a picture with a different GPS fix doesn't change the dive site.
>> Only if it has no GPS information does it get updated.
>>
>> /D
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
>
> --
> 
> Cu stima/Best regards/Mit freundlichen Grüßen,
>
> Chirana-Gheorghita Eugeniu-Theodor
> Bucharest, Romania
>
> e-mail : off...@adaptcom.ro
> mobile: 0743 698721
> 0747 447675
> SSI diver ID: 1118289
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

Sorry to be a party breaker but here it goes:
same tests done on windows and linux fedora with subsurface 4.9.4.80:

- create new dive, adjust time so I am in 30 mins after the dive
- save
- exit app
- open app , add picture >> no new dive site, no gps
- exit app
-open app > still no dive site , nor added to the dive nor in the general
dive sites tab
- delete dive

second test:

- create new dive, adjust time so I am in 30 mins after the dives
- name a test dive site for the dive with no gps
- save
- exit app
- open app , add picture >> no gps data added to the test dive site
- exit app
-open app > still no gps data on the dive site
- delete dive

third test on linux only for the other issue:

- create new dive site
- edit in dive planner and save , description get's populated with the dive
plan
- save , exit app
- open app and the dreaded error is there:
git-load: string marker after running out of strings ('description')







On Fri, May 8, 2020 at 10:50 PM Dirk Hohndel via subsurface <
subsurface@subsurface-divelog.org> wrote:

> On Fri, 2020-05-08 at 21:22 +0200, Willem Ferguson via subsurface
> wrote:
> >
> > Something I missed. If, for a dive, I have the dive location as a
> > named
> > dive site with coordinates and then attach a photo with other
> > coordinates, does anything happen? I tried this on my Ubuntu box and
> > I
> > could not see anything happening (correctly, I would think). The
> > photo
> > appeared in the Media tab for that dive and I could not find any new
> > location in dive site list.
>
> That's the expected behavior. If your dive site has a valid GPS fix,
> adding a picture with a different GPS fix doesn't change the dive site.
> Only if it has no GPS information does it get updated.
>
> /D
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>


-- 

Cu stima/Best regards/Mit freundlichen Grüßen,

Chirana-Gheorghita Eugeniu-Theodor
Bucharest, Romania

e-mail : off...@adaptcom.ro
mobile: 0743 698721
0747 447675
SSI diver ID: 1118289
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Dirk Hohndel via subsurface]

On Fri, 2020-05-08 at 21:22 +0200, Willem Ferguson via subsurface
wrote:
> 
> Something I missed. If, for a dive, I have the dive location as a
> named 
> dive site with coordinates and then attach a photo with other 
> coordinates, does anything happen? I tried this on my Ubuntu box and
> I 
> could not see anything happening (correctly, I would think). The
> photo 
> appeared in the Media tab for that dive and I could not find any new 
> location in dive site list.

That's the expected behavior. If your dive site has a valid GPS fix,
adding a picture with a different GPS fix doesn't change the dive site.
Only if it has no GPS information does it get updated.

/D

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

Re: quick update on test binaries

[Willem Ferguson via subsurface]

On 2020/05/08 18:06, Dirk Hohndel via subsurface wrote:
And it turns out that dives/images/wreck.jpg (which is part of the 
sources) does indeed contain GPS data,
so it's easy for everyone to test this by creating a dive 
around 2012-01-08 15:51:04


In my brief test on macOS with latest master (4.9.4-80) this appears 
to work as I would expect.


Thanks Theodor for pointing out the issues and Berthold for 
immediately fixing them!



Something I missed. If, for a dive, I have the dive location as a named 
dive site with coordinates and then attach a photo with other 
coordinates, does anything happen? I tried this on my Ubuntu box and I 
could not see anything happening (correctly, I would think). The photo 
appeared in the Media tab for that dive and I could not find any new 
location in dive site list.


Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: quick update on test binaries

[Willem Ferguson via subsurface]

On 2020/05/08 18:06, Dirk Hohndel via subsurface wrote:
And it turns out that dives/images/wreck.jpg (which is part of the 
sources) does indeed contain GPS data,
so it's easy for everyone to test this by creating a dive 
around 2012-01-08 15:51:04


In my brief test on macOS with latest master (4.9.4-80) this appears 
to work as I would expect.


Thanks Theodor for pointing out the issues and Berthold for 
immediately fixing them!


/D


I tested this with Ubuntu 18.04 and Subsurface 4.9.4-37. Everything 
works as expected. Created dive, added wreck photo, checked for a new 
dive site in the dive site tab.


Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: quick update on test binaries

[Dirk Hohndel via subsurface]

> On May 8, 2020, at 11:19 AM, Chirana Gheorghita Eugeniu Theodor 
>  wrote:
> 
> ios still does not have an update

I haven't found a way to automate that. I'm sure it exists, but as far as I can 
tell it is:

- start build on the one machine that has the keys
(sit around for ~3 minutes)

- open that build in Xcode, Archive it 
(sit around for another ~3-4 minutes)

- click on upload, click on Next on half a dozen dialogs, each time with a 
certain wait time
(now wait for the upload to complete, initial processing to complete... 2 to 10 
minutes, sometimes longer)

- open a web browser, log in, do the 2FA dance, accept another agreement on tax 
payments in in Southern Nirvana and the change to discount rules for central 
south Faringistan - even though you have ZERO paid apps, then agree to the 214 
page privacy policy that changes approximately every 9 days and that you can't 
accept until you SLOWLY scrolled all the way to the bottom

- navigate to the right screen again
- confirm that this still doesn't export weaponizable encryption technology
- submit for external testing

Now my work is done - average wall clock time spent ~30 minutes, but some days 
considerably longer, 99.99% of which is waiting and cursing

A random time interval later, this becomes available to testers.
Every time the version number is increased (so after every release) that 
typically takes 36-72 hours. Randomly it will take 12+ hours. But if version 
number is the same, most of the time it's just a few moments / minutes.


So yes, I am always behind on making iOS test binaries available. Because it's 
such an intentionally f-ing tedious process, such a waste of time, and (as I'm 
sure you can tell) it makes me SO ANGRY.
Oh, and every 365 days I get to pay $99 for the personal enjoyment to be 
allowed to do that. But I'm sure that price will increase any day now.

Anyway. I wrote this email during a couple of the "sit around" breaks in the 
list above. We are now in the "wait for the upload" stage and since this is the 
first 3.0.6 app we'll enter the wait typically 36-72h stage, soon.

/D

PS: I forgot to insert the "randomly be forced to update Xcode, update your OS, 
buy a new Mac, sacrifice a chicken or goat" stages that are also sprinkled into 
the process...
PPS: also forgot the "randomly one of the three different certificates that you 
need in the process expires and the automatic update fails and you manually 
reset it which resets all of your other certificates and then you end up doing 
a fresh macOS reinstall to get back to a working state" stage
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

ios still does not have an update

On Fri, May 8, 2020, 19:52 Chirana Gheorghita Eugeniu Theodor <
off...@adaptcom.ro> wrote:

> i used windows to test. and it's not my issue :))) i never use tagged gps
> images, 3 times put a image to a dive . But just for testing the app which
> I love and reccomend I do this. Usually I do not even have internet or
> location active on the phone :)
>
> I'll test this in 1 or 2 hours on ios and linux with latests binaries and
> let you know
>
> On Fri, May 8, 2020, 19:31 Berthold Stoeger 
> wrote:
>
>> On Freitag, 8. Mai 2020 18:06:45 CEST Dirk Hohndel wrote:
>> > And it turns out that dives/images/wreck.jpg (which is part of the
>> sources)
>> > does indeed contain GPS data, so it's easy for everyone to test this by
>> > creating a dive around 2012-01-08 15:51:04
>> >
>> > In my brief test on macOS with latest master (4.9.4-80) this appears to
>> work
>> > as I would expect.
>> >
>> > Thanks Theodor for pointing out the issues and Berthold for immediately
>> > fixing them!
>>
>> I don't think that Theodor's issue is fixed? Sadly, I can't reproduce it
>> though.
>>
>> Berthold
>>
>>
>>
>>
>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

i used windows to test. and it's not my issue :))) i never use tagged gps
images, 3 times put a image to a dive . But just for testing the app which
I love and reccomend I do this. Usually I do not even have internet or
location active on the phone :)

I'll test this in 1 or 2 hours on ios and linux with latests binaries and
let you know

On Fri, May 8, 2020, 19:31 Berthold Stoeger 
wrote:

> On Freitag, 8. Mai 2020 18:06:45 CEST Dirk Hohndel wrote:
> > And it turns out that dives/images/wreck.jpg (which is part of the
> sources)
> > does indeed contain GPS data, so it's easy for everyone to test this by
> > creating a dive around 2012-01-08 15:51:04
> >
> > In my brief test on macOS with latest master (4.9.4-80) this appears to
> work
> > as I would expect.
> >
> > Thanks Theodor for pointing out the issues and Berthold for immediately
> > fixing them!
>
> I don't think that Theodor's issue is fixed? Sadly, I can't reproduce it
> though.
>
> Berthold
>
>
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Berthold Stoeger via subsurface]

On Freitag, 8. Mai 2020 18:06:45 CEST Dirk Hohndel wrote:
> And it turns out that dives/images/wreck.jpg (which is part of the sources)
> does indeed contain GPS data, so it's easy for everyone to test this by
> creating a dive around 2012-01-08 15:51:04
> 
> In my brief test on macOS with latest master (4.9.4-80) this appears to work
> as I would expect.
> 
> Thanks Theodor for pointing out the issues and Berthold for immediately
> fixing them!

I don't think that Theodor's issue is fixed? Sadly, I can't reproduce it 
though.

Berthold




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

Re: quick update on test binaries

[Dirk Hohndel via subsurface]

And it turns out that dives/images/wreck.jpg (which is part of the sources) 
does indeed contain GPS data,
so it's easy for everyone to test this by creating a dive around 2012-01-08 
15:51:04

In my brief test on macOS with latest master (4.9.4-80) this appears to work as 
I would expect.

Thanks Theodor for pointing out the issues and Berthold for immediately fixing 
them!

/D

> On May 8, 2020, at 8:48 AM, Dirk Hohndel via subsurface 
>  wrote:
> 
> Apologies. The mailing list is set up to limit mail size (as the mails get 
> send to more than 300 people).
> I had planned to shrink your image, ensuring that the GPS info was retained, 
> and resending it... and got sidetracked and forgot.
> 
> /D
> 
>> On May 7, 2020, at 12:58 PM, Chirana Gheorghita Eugeniu Theodor 
>> mailto:off...@adaptcom.ro>> wrote:
>> 
>> I think is a problem with one of ny mail. the attached pic waits moserator 
>> something.
>> Even with addind a dive site with no gos and adding the pic , did not get 
>> any result in populating with gps data.
>> 
>> On Thu, May 7, 2020, 22:32 Chirana Gheorghita Eugeniu Theodor 
>> mailto:off...@adaptcom.ro>> wrote:
>> And another weird thing:
>> On the added manually dive the time is 1 hour over the local time. Now here 
>> is 22:31 and the dive time that is automatically added is 23:31
>> 
>> On Thu, May 7, 2020 at 10:14 PM Chirana Gheorghita Eugeniu Theodor 
>> mailto:off...@adaptcom.ro>> wrote:
>> Ok did it. no gps data get's asdigned to the dive site. Attached the pic i 
>> use
>> 
>> On Thu, May 7, 2020, 21:51 Dirk Hohndel > > wrote:
>> 
>> 
>> > On May 7, 2020, at 11:35 AM, Chirana Gheorghita Eugeniu Theodor 
>> > mailto:off...@adaptcom.ro>> wrote:
>> > 
>> > So more testing. As I said with pics it works except for the gps data from 
>> > pic. I cannot figure how to import that data . 
>> 
>> I personally have never used that (as all of my devices have been set up to 
>> NEVER record GPS locations in pictures).
>> It seems to me that in dive.c / create_picture() we are extracting the 
>> location from the EXIF information and then call
>> dive_set_geodata_from_picture() - reading that function, what is needed is 
>> that your dive does have a location (i.e. a dive_site),
>> but that the dive_site has no GPS data associated with it.
>> 
>> So to test this theory, can you go back, make sure your manually created 
>> dive has a dive_site but no GPS, and then add the picture to it?
>> 
>> > I just pened the dive in dive planned, saved the dive, and the description 
>> > gets populated with the calculated dive plan. I save to cloud and when 
>> > opening again I see this error on the bottom of the screen:
>> > git-load: string marker after running out of strings ('description')
>> 
>> I have seen this as well and need to figure out why we still show this. I 
>> thought we had agreed that this is not an actual error we want to report :-(
>> 
>> > I delete the description , save to cloud, close the app and open again. 
>> > Same error.
>> > Delete the dive and save to cloud, reopen app and error is gone.
>> > Add dive again manually again save to cloud, close app and reopen and 
>> > error is gone.
>> > 
>> > So If I open the dive again in planner with no pic attached and save the 
>> > dive, description gets populated, save to cloud and when opening same 
>> > error.
>> > Deleting that dive and just typing test.ing word in another dive 
>> > description, save and close at reopen no more error
>> > Seems it has a issue with description field beeing to long ?
>> 
>> That definitely needs more investigation. I'll try to reproduce
>> 
>> Thank you!
>> 
>> /D
>> 
>> 
>> 
>> -- 
>> 
>> Cu stima/Best regards/Mit freundlichen Grüßen,
>> 
>> Chirana-Gheorghita Eugeniu-Theodor
>> Bucharest, Romania
>> 
>> e-mail : off...@adaptcom.ro 
>> mobile: 0743 698721
>> 0747 447675
>> SSI diver ID: 1118289
> 
> ___
> 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: quick update on test binaries

[Dirk Hohndel via subsurface]

> On May 8, 2020, at 4:30 AM, Chirana Gheorghita Eugeniu Theodor 
>  wrote:
> 
> pictite sent. Unfortunatly i repeated the test and no unnamed dive sites 
> created, no location imported. even with the tick on load file even date does 
> not match

Interesting.
Since you are testing on so many platforms, which one did you run this test on?
I will merge Berthold's PR so you and he test with the same version... new 
binaries should be up in <15 minutes.

/D

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

Re: quick update on test binaries

[Dirk Hohndel via subsurface]

Apologies. The mailing list is set up to limit mail size (as the mails get send 
to more than 300 people).
I had planned to shrink your image, ensuring that the GPS info was retained, 
and resending it... and got sidetracked and forgot.

/D

> On May 7, 2020, at 12:58 PM, Chirana Gheorghita Eugeniu Theodor 
>  wrote:
> 
> I think is a problem with one of ny mail. the attached pic waits moserator 
> something.
> Even with addind a dive site with no gos and adding the pic , did not get any 
> result in populating with gps data.
> 
> On Thu, May 7, 2020, 22:32 Chirana Gheorghita Eugeniu Theodor 
> mailto:off...@adaptcom.ro>> wrote:
> And another weird thing:
> On the added manually dive the time is 1 hour over the local time. Now here 
> is 22:31 and the dive time that is automatically added is 23:31
> 
> On Thu, May 7, 2020 at 10:14 PM Chirana Gheorghita Eugeniu Theodor 
> mailto:off...@adaptcom.ro>> wrote:
> Ok did it. no gps data get's asdigned to the dive site. Attached the pic i use
> 
> On Thu, May 7, 2020, 21:51 Dirk Hohndel  > wrote:
> 
> 
> > On May 7, 2020, at 11:35 AM, Chirana Gheorghita Eugeniu Theodor 
> > mailto:off...@adaptcom.ro>> wrote:
> > 
> > So more testing. As I said with pics it works except for the gps data from 
> > pic. I cannot figure how to import that data . 
> 
> I personally have never used that (as all of my devices have been set up to 
> NEVER record GPS locations in pictures).
> It seems to me that in dive.c / create_picture() we are extracting the 
> location from the EXIF information and then call
> dive_set_geodata_from_picture() - reading that function, what is needed is 
> that your dive does have a location (i.e. a dive_site),
> but that the dive_site has no GPS data associated with it.
> 
> So to test this theory, can you go back, make sure your manually created dive 
> has a dive_site but no GPS, and then add the picture to it?
> 
> > I just pened the dive in dive planned, saved the dive, and the description 
> > gets populated with the calculated dive plan. I save to cloud and when 
> > opening again I see this error on the bottom of the screen:
> > git-load: string marker after running out of strings ('description')
> 
> I have seen this as well and need to figure out why we still show this. I 
> thought we had agreed that this is not an actual error we want to report :-(
> 
> > I delete the description , save to cloud, close the app and open again. 
> > Same error.
> > Delete the dive and save to cloud, reopen app and error is gone.
> > Add dive again manually again save to cloud, close app and reopen and error 
> > is gone.
> > 
> > So If I open the dive again in planner with no pic attached and save the 
> > dive, description gets populated, save to cloud and when opening same error.
> > Deleting that dive and just typing test.ing word in another dive 
> > description, save and close at reopen no more error
> > Seems it has a issue with description field beeing to long ?
> 
> That definitely needs more investigation. I'll try to reproduce
> 
> Thank you!
> 
> /D
> 
> 
> 
> -- 
> 
> Cu stima/Best regards/Mit freundlichen Grüßen,
> 
> Chirana-Gheorghita Eugeniu-Theodor
> Bucharest, Romania
> 
> e-mail : off...@adaptcom.ro 
> mobile: 0743 698721
> 0747 447675
> SSI diver ID: 1118289

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

Re: Proposal: Statistics in Subsurface

[Dirk Hohndel via subsurface]

Hi Tomaz

> On May 8, 2020, at 6:40 AM, Tomaz Canabrava  wrote:
> 
> (Puff)
> 
> This was my last serious attempt to do something userfull to subsurface, 
> almost 4 years ago. I basically gave up with around 120 - 140 commits because 
> no way I did pleased everyone.

To this day I consider my failure to guide you to something I felt comfortable 
merging as one of my low points as maintainer.
And in many ways, that's the key reason why I push so hard that we have a 
visual design that people agree upon before embarking on the next 
implementation.

> It’s something I would like to get it right, tougth.
> 
> I’ll try again.

I'm impressed by your persistence. Yes, that would of course be extremely 
welcome. I'd love to have you back as an active contributor!

> Dirk, there’s a chart qml library that I’m using for a personal project, not 
> qt quick charts, that thing is broken by design, that I think it can work.

There are a number of different libraries that I saw when I did a quick survey. 
I'm curious which one you settled on (and why).

Thanks

/D

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

Re: Proposal: Statistics in Subsurface

[Tomaz Canabrava via subsurface]

(Puff)

This was my last serious attempt to do something userfull to subsurface,
almost 4 years ago. I basically gave up with around 120 - 140 commits
because no way I did pleased everyone.

It’s something I would like to get it right, tougth.

I’ll try again.

Dirk, there’s a chart qml library that I’m using for a personal project,
not qt quick charts, that thing is broken by design, that I think it can
work.

Best
Tomaz

On Thu, 7 May 2020 at 21:47 Chirana Gheorghita Eugeniu Theodor via
subsurface  wrote:

> I would redesign the statistics page on using a default chart and a
> dropdown at the top to select more granular things like yearly, monthly.
> when selected the chart just readjust dinamic
> Only one tab. more tabs gets confusing and crowdint the screen.
> Just an idea.
>
> On Thu, May 7, 2020, 18:37 Dirk Hohndel via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
>> On Thu, 2020-05-07 at 14:37 +0200, Willem Ferguson via subsurface
>> wrote:
>> > I have been thinking  a long time about graphical statistics
>> > facilities
>> > for Subsurface, that is presenting the dive statistics as bar graphs
>> > or
>> > other types of graphics.
>>
>> This is a topic that we have tried to tackle for something like 5 years
>> now. And it is a tough one, in large part because I strongly believe
>> that if we do spend the effort to do this, we should do so in a way
>> that works both for desktop and mobile - because better statistics are
>> the #1 request for the mobile app (ahead of an implementation of the
>> planner).
>>
>> Which means this should ideally be implemented in much of the same way
>> as the Maps. As a QML module that can be used in both apps. Which makes
>> things harder - but I strongly believe is the right thing to do.
>>
>> How we should start is with a drawing board and sketches. What are we
>> visualizing? Which numbers and data points are likely to be most
>> interesting and useful for people - we have learned in the past that
>> the answers to this vary shockingly widely. And equally importand, how
>> are we visualizing this - just draw things with a pen on paper and send
>> a picture...
>>
>> Once we have that, we can look more into how to implement this. The
>> available QML modules for graphics are limited. Check here for a quick
>> intro:
>> https://doc.qt.io/qt-5/qtcharts-qmlchart-example.html
>> Yes, there are much more powerful toolkits available, but I haven't
>> found one that doesn't add significant overhead for the mobile
>> platforms.
>> Someone pointed out to me a while ago that we might be able to use a
>> full Javascript charts framework like https://www.chartjs.org/ this
>> will require some experimentation for iOS and Android. If someone
>> wanted to tackle THAT question (which could happen in parallel to the
>> work on the actual design above), that would be great.
>>
>> > 1) In doing so, I looked at the yearly statistics as implemented at
>> > the
>> > moment and realised that this is actually a pretty comprehensive
>> > statistical framework and that it would be inefficient to write a
>> > separate code base for graphical statistical presentation. The
>> > current
>> > code for statistics is somewhat complicated but perfectly workable.
>>
>> Correct me if I'm wrong, but I thought that both the yearly statistics
>> and the statistics tab use the same backend code (basically
>> statistics.c)
>>
>> > 2) The current statistics tab, accessible from the Notes Panel (i.e.
>> > the
>> > statistics tab adjacent to the Information tab) actually largely
>> > duplicates what can be obtained from the Yearly statistics panel.
>> > The
>> > only difference is that, currently, the Yearly statistics calculates
>> > results based on the whole dive log, while the Statistic tab
>> > presents
>> > results for all the dives selected on the dive list. However,
>> > yearlystatisticsmodel.cpp already already has code that in principle
>> > allows calculations for the *selected* dives in the dive log: it is
>> > just
>> > not activated as far as I can see.
>>
>> Again, I believe that this is all using the same backend code. And
>> ideally we really want to have just ONE spot where we calculate things
>> and have the UI layer just deal with how things are presented to the
>> user. Typically in the past our code wasn't always very careful in
>> following these design goals.
>>
>> > 3) The main problem with the yearly statistics is that the table is
>> > pretty large. In order to make this more user friendly, my proposal
>> > is
>> > to break the yearly statistics table into smaller chunks and move
>> > them
>> > over to the Statistics tab.
>>
>> Yes, the visualization is not great (to be kind)
>>
>> > 4) This would bring all the statistics together in one place. Seeing
>> > that the info in the Statistics tab has no one-to-one connection
>> > with
>> > the dive profile being displayed, the question arises: should the
>> > statistics tab not be elevated to the main menu rather than a tab

Re: quick update on test binaries

[Chirana Gheorghita Eugeniu Theodor via subsurface]

pictite sent. Unfortunatly i repeated the test and no unnamed dive sites
created, no location imported. even with the tick on load file even date
does not match

On Fri, May 8, 2020, 12:57 Berthold Stoeger 
wrote:

> On Donnerstag, 7. Mai 2020 20:51:02 CEST Dirk Hohndel via subsurface wrote:
> > > On May 7, 2020, at 11:35 AM, Chirana Gheorghita Eugeniu Theodor
> > >  wrote:
> > >
> > > So more testing. As I said with pics it works except for the gps data
> from
> > > pic. I cannot figure how to import that data .
> > I personally have never used that (as all of my devices have been set up
> to
> > NEVER record GPS locations in pictures). It seems to me that in dive.c /
> > create_picture() we are extracting the location from the EXIF information
> > and then call dive_set_geodata_from_picture() - reading that function,
> what
> > is needed is that your dive does have a location (i.e. a dive_site), but
> > that the dive_site has no GPS data associated with it.
>
> It seems that you are looking at an old version. create_picture() is in
> picture.c since the undoization of media.
>
> Moreover, if the dive doesn't have a dive site, a dive site is created.
> Sadly,
> the site was given an empty name, though that should be fixed by
> https://github.com/subsurface/subsurface/pull/2825
>
> Theodor sent me the picture in question. Weirdly, for me it (mostly)
> works,
> both with a dive site without GPS location and without a dive site. It
> just
> seems that the flag is not immediately updated on the map. The only thing
> to
> take care of is the check the "Load media files even the time does not
> match"
> box.
>
> Berthold
>
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: quick update on test binaries

[Berthold Stoeger via subsurface]

On Donnerstag, 7. Mai 2020 20:51:02 CEST Dirk Hohndel via subsurface wrote:
> > On May 7, 2020, at 11:35 AM, Chirana Gheorghita Eugeniu Theodor
> >  wrote:
> > 
> > So more testing. As I said with pics it works except for the gps data from
> > pic. I cannot figure how to import that data .
> I personally have never used that (as all of my devices have been set up to
> NEVER record GPS locations in pictures). It seems to me that in dive.c /
> create_picture() we are extracting the location from the EXIF information
> and then call dive_set_geodata_from_picture() - reading that function, what
> is needed is that your dive does have a location (i.e. a dive_site), but
> that the dive_site has no GPS data associated with it.

It seems that you are looking at an old version. create_picture() is in 
picture.c since the undoization of media.

Moreover, if the dive doesn't have a dive site, a dive site is created. Sadly,
the site was given an empty name, though that should be fixed by
https://github.com/subsurface/subsurface/pull/2825

Theodor sent me the picture in question. Weirdly, for me it (mostly) works, 
both with a dive site without GPS location and without a dive site. It just 
seems that the flag is not immediately updated on the map. The only thing to 
take care of is the check the "Load media files even the time does not match" 
box.

Berthold 


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

Re: quick update on test binaries

[Berthold Stoeger via subsurface]

On Donnerstag, 7. Mai 2020 20:15:52 CEST Chirana Gheorghita Eugeniu Theodor 
via subsurface wrote:
> adding pictures is ok. deletimg them also ok,
> recalculate thimbnails ok.
> I do not see any gps data omported. Can you explain how the flow should
> work. I used a pic taken 30 minutes after the created dive time andI do
> not see any new dive site

This appears to work for me with the "wreck.jpg" test picture, for a dive 
without divesite as well as for a dive with a divesite with GPS coordinates. 
The UI experience for the first case is bad, as it creates a dive site without 
name. That will have to be improved.

Therefore, I would conclude that we can't parse the GPS data of the picture. 
If you send it to me in private, I can have a look.

Berthold


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

Re: quick update on test binaries

[Berthold Stoeger via subsurface]

On Donnerstag, 7. Mai 2020 21:32:04 CEST Chirana Gheorghita Eugeniu Theodor 
via subsurface wrote:
> And another weird thing:
> On the added manually dive the time is 1 hour over the local time. Now here
> is 22:31 and the dive time that is automatically added is 23:31

This appears to be by design. It was introduced in commit 
611bae344111845bfa8bd676c0fad49d1c051c10 (Jul 2014) and can be traced back to 
commit be9be189f7350cfb92899680907735719566631e (Jan 2013). It comes from the 
dive planner, where obviously you plan a dive in the future.

Berthold


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