Subsurface-mobile 2.0 Android beta released

2017-07-08 Thread Dirk Hohndel

Those of you who are part of the Google Play beta group should have seen an 
announcement - otherwise manually check for updates in the Google Play app.

There's a blog post about it here: 
https://subsurface-divelog.org/2017/07/first-beta-of-subsurface-mobile-2-0/ 

which also explains how to join the beta group.

Sources are pushed to git, and of course an APK is available directly as well: 
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.363-arm.apk
 

 

This is far from perfect, but it should get us started. And get us a lot more
testing and feedback, I hope.

Thanks to everyone who helped make this happen!

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


Crash with Subsurface-mobile on Android V4.3

2017-06-28 Thread Willem Ferguson
>From phone. When running Subsurface-mobile build 4.283, the app crashes
when one exits from Subsurface on Android 4.3. Attached is adb output
 (shortened). This is a tar.gz file. My phone has restrictions on file
types that can be attached to mail, therefore the. Pdf file type.
Kind regards,
Willem
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Building Subsurface-mobile for Android

2017-05-27 Thread Dirk Hohndel
Please read the top of the packaging/android/android-build-wrapper.sh file for 
information about this

/D

> On May 25, 2017, at 12:13 AM, Willem Ferguson 
>  wrote:
> 
> I am attempting to build the Android version of Subsurface and get:
> 
> ~/src
> -- building with libftdi support
> -- system name Android
> -- Found Qt for Android: /home/willem/src/Qt/5.8/android_armv7
> -- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
> -- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
> -- Configuring done
> CMake Error in CMakeLists.txt:
>  No known features for CXX compiler
> 
>  "GNU"
> 
>  version 4.9.
> 
> Activating set(CMAKE_VERBOSE_MAKEFILE ON) does not give more information.
> 
> What could the problem be?
> 
> Kind regards,
> 
> willem
> 
> 
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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


Re: Building Subsurface-mobile for Android

2017-05-26 Thread Jan Mulder

On 25-05-17 09:13, Willem Ferguson wrote:

I am attempting to build the Android version of Subsurface and get:

~/src
-- building with libftdi support
-- system name Android
-- Found Qt for Android: /home/willem/src/Qt/5.8/android_armv7
-- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
-- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
-- Configuring done
CMake Error in CMakeLists.txt:
  No known features for CXX compiler

  "GNU"

  version 4.9.

Activating set(CMAKE_VERBOSE_MAKEFILE ON) does not give more information.

What could the problem be?

Kind regards,

willem


Willem, yes, cross-building for Android can be a real pain. it is very 
difficult to determine what the cause of your build problem is. I assume 
that you are trying to compile using the build.sh script in 
packaging/android? Yesterday, I ran into multiple build problems when 
trying to build myself. To be sure that all dependencies are compiled, I 
manually remove the *_arm directories, before running the 
packaging/android/build.sh. For the record, I do not use the 
android-build-wrapper.sh script. This just downloads NDK/SDK/Qt 
dependencies that I have already have on my system, so I just point the 
build.sh to the already installed NDK/SDK/Qt.


I added a pull request (yesterday) related to Android builds: see 
https://github.com/Subsurface-divelog/subsurface/pull/405. But I do not 
see how this can be related to your build issue.


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


Building Subsurface-mobile for Android

2017-05-25 Thread Willem Ferguson

I am attempting to build the Android version of Subsurface and get:

~/src
-- building with libftdi support
-- system name Android
-- Found Qt for Android: /home/willem/src/Qt/5.8/android_armv7
-- Found Android SDK: /home/willem/src/subsurface/../android-sdk-linux
-- Found Android NDK: /home/willem/src/subsurface/../android-ndk-r13b
-- Configuring done
CMake Error in CMakeLists.txt:
  No known features for CXX compiler

  "GNU"

  version 4.9.

Activating set(CMAKE_VERBOSE_MAKEFILE ON) does not give more information.

What could the problem be?

Kind regards,

willem


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


Re: Subsurface-mobile on Android

2016-08-29 Thread Adric Norris
Version 4.5.2.1569 seems to be working fine here (stock Android 7.0 on a
Nexus 6P).

On Sun, Aug 28, 2016 at 9:58 PM, Dirk Hohndel  wrote:

>
> > On Aug 28, 2016, at 7:54 PM, Richard DePas 
> wrote:
> >
> > I was able to install it without uninstalling the previous version. It
> also seems to be be working for me. Pulled up all my dives and was able to
> navigate around just fine.
>
> Excellent. That’s what I was hoping… Now I just need to see if the test
> also
> succeeds for people on Android Nougat. I see no reason why it shouldn’t,
> but you never know…
>
> Thanks for the immediate response!
>
> /D
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>



-- 
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." -Douglas Adams
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile on Android

2016-08-28 Thread Dirk Hohndel

> On Aug 28, 2016, at 7:54 PM, Richard DePas  wrote:
> 
> I was able to install it without uninstalling the previous version. It also 
> seems to be be working for me. Pulled up all my dives and was able to 
> navigate around just fine.

Excellent. That’s what I was hoping… Now I just need to see if the test also
succeeds for people on Android Nougat. I see no reason why it shouldn’t,
but you never know…

Thanks for the immediate response!

/D

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


Re: Subsurface-mobile on Android

2016-08-28 Thread Dirk Hohndel

> On Aug 28, 2016, at 7:50 PM, Rick Walsh  wrote:
> 
> 
> 
> On 29 August 2016 at 12:41, Dirk Hohndel  > wrote:
> 
> Please try
> 
> http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1564-release-arm.apk
>  
> 
> 
> This should both work on Android 7 (but someone please verify, I didn’t bring 
> a phone with Android 7 to Las Vegas) and on the phones where the previous 
> version failed.
> 
> I’d really appreciate if people could verify both of these statements.
> 
> 
> I needed to uninstall the previous (1535) build before I could install the 
> latest.  Did you sign with the same key?

Yes. That’s the difference between the -release-arm.apk and the other one. 
I guess I can stop making that other one now… initially I only released the 
APKs on the website… and the release one had a different key. So I started
making two so people could seamlessly upgrade. No idea why this failed for you.

> Other than that, it seems to work in my 2 minutes of testing: I could enter 
> my credentials, sync with cloud, and view a few dives.  I didn't try anything 
> more sophisticated than that.

Well - “WORKS” is always a welcome test result.

Thanks for the immediate response!

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


Re: Subsurface-mobile on Android

2016-08-28 Thread Richard DePas
I was able to install it without uninstalling the previous version. It also
seems to be be working for me. Pulled up all my dives and was able to
navigate around just fine.

- Rich

On Sun, Aug 28, 2016 at 7:51 PM Rick Walsh  wrote:

> On 29 August 2016 at 12:41, Dirk Hohndel  wrote:
>
>>
>> Please try
>>
>>
>> http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1564-release-arm.apk
>>
>> This should both work on Android 7 (but someone please verify, I didn’t
>> bring a phone with Android 7 to Las Vegas) and on the phones where the
>> previous version failed.
>>
>> I’d really appreciate if people could verify both of these statements.
>>
>>
>> I needed to uninstall the previous (1535) build before I could install
> the latest.  Did you sign with the same key?
>
> Other than that, it seems to work in my 2 minutes of testing: I could
> enter my credentials, sync with cloud, and view a few dives.  I didn't try
> anything more sophisticated than that.
>
> Rick
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-- 
- Rich
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile on Android

2016-08-28 Thread Thomas Maisl (mobile)
Hi, 

The current release fails on my CM 11 / Android 4.4.4 device, too. 

I'll try to figure out how to get log files. 

Thomas

Am 28. August 2016 20:55:00 MESZ, schrieb Dirk Hohndel :
>
>It seems that when I pushed the latest build (the one that works on
>Nougat) to production, things started to fail for a few of our users.
>And of course instead of sending email to ask for help, we are getting
>one and two star reviews instead. Great.
>
>Anyway… could those on Android try if they can reproduce it? One person
>contacted me by email and the logs on his system are just strange…
>
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,Trying to load lib
>/data/app-lib/org.subsurfacedivelog.mobile-1/libssl.so 0x41b3a160
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,Added shared lib
>/data/app-lib/org.subsurfacedivelog.mobile-1/libssl.so 0x41b3a160
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,No JNI_OnLoad found in
>/data/app-lib/org.subsurfacedivelog.mobile-1/libssl.so 0x41b3a160,
>skipping init
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,Trying to load lib
>/data/app-lib/org.subsurfacedivelog.mobile-1/libcrypto.so 0x41b3a160
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,Added shared lib
>/data/app-lib/org.subsurfacedivelog.mobile-1/libcrypto.so 0x41b3a160
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,No JNI_OnLoad found in
>/data/app-lib/org.subsurfacedivelog.mobile-1/libcrypto.so 0x41b3a160,
>skipping init
>2016-08-28 11:48:07,DEBUG,dalvikvm,Unknown,Trying to load lib
>/data/app-lib/org.subsurfacedivelog.mobile-1/libssh2.so 0x41b3a160
>2016-08-28
>11:48:07,ERROR,dalvikvm,Unknown,dlopen("/data/app-lib/org.subsurfacedivelog.mobile-1/libssh2.so")
>failed: dlopen failed: cannot locate symbol "EVP_cast5_cbc" referenced
>by "libssh2.so"...
>
>
>So it’s loading lib crypto.so successfully 
>
>$ nm libcrypto.so | grep EVP_cast5
>000c3a38 T EVP_cast5_cbc
>
>which contains the symbol that it then claims it can’t find.
>
>I’m completely baffled.
>
>I don’t know, yet, if that’s the common problem for everyone, but more
>data points (or even better, a fix) would be very welcome.
>
>Of course it works on the two Android phones I have tested it on (Nexus
>6P with 6.0.1 and 5X with 7.0)
>
>Thanks
>
>/D
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
"Si Non Confectus Non Reficat" (The Patrician - Terry Pratchett)___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile on Android

2016-08-28 Thread Rick Walsh
On 29 August 2016 at 12:41, Dirk Hohndel  wrote:

>
> Please try
>
> http://subsurface-divelog.org/downloads/daily/Subsurface-
> mobile-4.5.2.1564-release-arm.apk
>
> This should both work on Android 7 (but someone please verify, I didn’t
> bring a phone with Android 7 to Las Vegas) and on the phones where the
> previous version failed.
>
> I’d really appreciate if people could verify both of these statements.
>
>
> I needed to uninstall the previous (1535) build before I could install the
latest.  Did you sign with the same key?

Other than that, it seems to work in my 2 minutes of testing: I could enter
my credentials, sync with cloud, and view a few dives.  I didn't try
anything more sophisticated than that.

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


Re: Subsurface-mobile on Android

2016-08-28 Thread Dirk Hohndel
Please try

http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1564-release-arm.apk
 


This should both work on Android 7 (but someone please verify, I didn’t bring a 
phone with Android 7 to Las Vegas) and on the phones where the previous version 
failed.

I’d really appreciate if people could verify both of these statements.

Thanks

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


Re: Subsurface-mobile on Android

2016-08-28 Thread Dirk Hohndel


On August 28, 2016 3:45:58 PM PDT, Rick Walsh  wrote:
>On 29 Aug 2016 04:55, "Dirk Hohndel"  wrote:
>>
>>
>> It seems that when I pushed the latest build (the one that works on
>Nougat) to production, things started to fail for a few of our users.
>And
>of course instead of sending email to ask for help, we are getting one
>and
>two star reviews instead. Great.
>>
>That's annoying. The way the Android store is set up, it makes it much
>easier to review than send an email. Having said that, no 2star reviews
>are
>showing up for me.

I responded to all of those reviews asking people to contact me. Maybe you 
don't see it because it was in German? I can still see it in the Google Play 
Console.

>The latest daily is working fine on my Galaxy S6, Android 6.01

Thanks. Same on my Nexus 6p. So it works on some 6.0.1 phones and fails on 
others. Very annoying.

/D

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


Re: Subsurface-mobile on Android

2016-08-28 Thread Joakim Bygdell

> On 28 Aug 2016, at 20:55, Dirk Hohndel  wrote:
> 
> 
> I’m completely baffled.
> 
> I don’t know, yet, if that’s the common problem for everyone, but more data 
> points (or even better, a fix) would be very welcome.
> 
> Of course it works on the two Android phones I have tested it on (Nexus 6P 
> with 6.0.1 and 5X with 7.0)

The "Android 7.0" patch causes my builds to crash on startup on my phone 
(6.0.1), 
can’t give any more than that at the moment as I haven’t tried to collect any 
debug data yet.

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

/Jocke

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


Re: Subsurface-mobile on Android 7.0 / Nougat

2016-08-24 Thread Adric Norris
Version 4.5.2.1535 does indeed fix the issue for me on Android 7.0
(Nougat). (-;

On Aug 24, 2016 4:09 PM, "Dirk Hohndel"  wrote:

>
> After reading a bit more of the documentation that Google provided
> regarding the
> change with regard to native libraries and reading about other projects
> cursing and
> complaining until they got this to work, I believe that my first attempt
> to fix this was
> exactly the wrong thing to do.
>
> Yes, you are not supposed to dynamically link against native libraries
> that aren’t
> part of the official API. But that doesn’t mean that you should statically
> link against
> them, instead I now believe that it means you should dynamically link
> against them
> and bundle them with your app.
>
> So that’s what I tried to do: 4.5.2-1355 should be on its way to the
> Google Play
> Alpha channel and is also already available for direct download on
> downloads/daily
>
> I tested this on 6.0.1, but NOT YET on 7.0. So I don’t think I broke what
> worked
> before, but I haven’t been able to verify that this actually fixes the
> problem on
> Android 7.0 / Nougat.
>
> I know that some of you have already received either a 7.0 preview or even
> the
> final build on your devices. Please test -1355 so I know if this actually
> fixes things…
>
> Thanks
>
> /D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Subsurface-mobile on Android 7.0 / Nougat

2016-08-24 Thread Dirk Hohndel

After reading a bit more of the documentation that Google provided regarding 
the 
change with regard to native libraries and reading about other projects cursing 
and 
complaining until they got this to work, I believe that my first attempt to fix 
this was 
exactly the wrong thing to do. 

Yes, you are not supposed to dynamically link against native libraries that 
aren’t 
part of the official API. But that doesn’t mean that you should statically link 
against 
them, instead I now believe that it means you should dynamically link against 
them 
and bundle them with your app.

So that’s what I tried to do: 4.5.2-1355 should be on its way to the Google Play
Alpha channel and is also already available for direct download on 
downloads/daily

I tested this on 6.0.1, but NOT YET on 7.0. So I don’t think I broke what worked
before, but I haven’t been able to verify that this actually fixes the problem 
on
Android 7.0 / Nougat.

I know that some of you have already received either a 7.0 preview or even the
final build on your devices. Please test -1355 so I know if this actually fixes 
things…

Thanks

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


Re: Subsurface-mobile for Android has been released

2016-03-14 Thread Adric Norris
On Sat, Mar 12, 2016 at 3:11 PM, Dirk Hohndel  wrote:

> https://www.facebook.com/subsurfacedivelog/ (I'm not sure how to link to
> a specific post on the page...)
>
>
Once the item has been submitted, you can get the direct URL from the
date/time link at the top of the post. In this case it's
https://www.facebook.com/subsurfacedivelog/posts/1012304812149792.

While it doesn't matter here, in general I'd recommend verifying the URL in
private/incognito mode before sharing it via another forum. This is because
some Facebook posts are private, so they won't always be publicly usable.

-- 
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." -Douglas Adams
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android first release

2016-03-13 Thread Thomas Pfeiffer
On Saturday, 12 March 2016 07:49:13 CET you wrote:

> > What exactly is the problem? Does it not draw the content fast enough
> > while
> > scrolling? Or is it about blank space at the very end of the list?
> > ___
> > subsurface mailing list
> > subsurface@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> Thomas,
> Here is a link to a video showing this effect. Unfortunately the mp4
> file is some 37 Mb in size.
> 
> https://www.dropbox.com/s/cw887nmq7oqy9va/REC_1457760197842.mp4?dl=0

Hi Willem,
thank you for the demonstration!
Now I can at least say that this is not intended. 
The Kirigami list component allows developers to set a certain margin by which 
a list can be "overscrolled" at the beginning or end to allow users to scroll 
the first/last entry to a point where they are easily accessible while holding 
the phone with one hand, but Subsurface mobile currently does not use this, 
and even if it did, there should definitely not be a whole blank page.

Best,
Thomas

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


Re: Subsurface-mobile for Android has been released

2016-03-13 Thread Dirk Hohndel

> On Mar 13, 2016, at 3:15 AM, Robert Helling  wrote:
> 
> Hi,
> 
> congratulations to everybody who helped getting this mobile version to work!
> 
> Just a quick report: I shared the FB announcement to a few German scuba 
> diving groups. It immediately got a number of likes but also two independent 
> comments (in two different groups) that commented that it is „just another 
> untrustworthy cloud service“. I wrote back that this is what you have to do 
> if you want to sync a log book with the desktop. It’s only that currently US 
> based cloud services are very unpopular here for privacy reasons. Just FYI. 

I will miss the tremendous revenue that I would have gotten from these people.

/D

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


Re: Subsurface-mobile for Android has been released

2016-03-13 Thread Robert Helling
Hi,

congratulations to everybody who helped getting this mobile version to work!


> On 12.03.2016, at 22:11, Dirk Hohndel  wrote:
> 
> And of course please post announcements to local or special interest forums - 
> ideally with links to the announcement on our website or at least to Google 
> Play and to the user manual and user forum.
> 

Just a quick report: I shared the FB announcement to a few German scuba diving 
groups. It immediately got a number of likes but also two independent comments 
(in two different groups) that commented that it is „just another untrustworthy 
cloud service“. I wrote back that this is what you have to do if you want to 
sync a log book with the desktop. It’s only that currently US based cloud 
services are very unpopular here for privacy reasons. Just FYI.

Best
Robert


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Willem Ferguson

On 11/03/2016 17:35, Thomas Pfeiffer wrote:

On Friday, 11 March 2016 06:58:17 CET Dirk Hohndel wrote:


Scroll to bottom of dive list.
* Same problem as previously reported: parts of screen is white.
This is worse if one scrolls rapidly.

This is either a QML problem or a Kirigami problem. We have nothing in our
code that impacts how this is shown. We need to talk to the QML experts
about this, but their responses so far to our other report aren't
encouraging.

What exactly is the problem? Does it not draw the content fast enough while
scrolling? Or is it about blank space at the very end of the list?
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Thomas,
Here is a link to a video showing this effect. Unfortunately the mp4 
file is some 37 Mb in size.


https://www.dropbox.com/s/cw887nmq7oqy9va/REC_1457760197842.mp4?dl=0

Kind regards,
willem

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel
Marco... HELP

On Fri, Mar 11, 2016 at 08:16:46AM -0800, Dirk Hohndel wrote:
> > But still this does not guarantee that I do not run out of RAM on 5.1.1 
> > because who knows how Android 5.1.1 does memory management compared to 
> > Android 4.3? On the S3 the mobile app is rock-solid.
> > 
> > I forgot to mention one thing. On both the S3 and the S6 using build 1058, 
> > when I delete a dive the undo button does not appear at all.
> 
> I will look into this. Yet another show stopper :-(
> Undo really has to work or people will be unhappy.

And indeed we have a show stopper. 

I can reproduce this. I added a ton of debug output to the Kirigami
components. We call showPassiveNotification with the right text and
button. The animation is run just as it is when we show the notification
for cloud access (which works). But the delete notification / undo button
never get shown. Then the timer expires and the notification area (which
was never shown) gets hidden and the chance for undo is gone.

This worked just a week or two ago and is now broken. I can reproduce this
both on the desktop and on multiple Android devices. 

:-(

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Lubomir I. Ivanov
On 11 March 2016 at 18:16, Dirk Hohndel  wrote:
>
>> On Mar 11, 2016, at 7:39 AM, Willem Ferguson 
>>  wrote:
>>
>> On 11/03/2016 16:58, Dirk Hohndel wrote:
>>>
>>> I wonder if you are running out of memory. Subsurface (because of the way
>>> it is built, and the interaction with git) is a fairly memory hungry
>>> application... what phone/tablet is that on? Do you happen to know how
>>> much memory that device has?
>>>
>>> /D
>>>
>> I use a Samsung Galaxy S6 Edge with 32 Gb RAM. I run the software no problem 
>> at all on my wife's Galaxy S3 with only 8 Gb RAM.
>
> I'm 99.999% sure that you are talking about the amount of flash in those 
> devices, not RAM. I think I've seen reports of 8GB phones, but I don't think 
> any ship, yet. Most phones have between 2GB and 4GB RAM these days, some 1GB. 
> And it's the 1GB ones where I worry that we might run out of memory.
>

TMK, apps running in the Java virtual machine on Android have an
imposed memory limit, but one time i've tested that and it seemed as
if my app was able to use a lot more - around 100MB, while the limit
was supposedly lower.

for native applications (NDK):
https://groups.google.com/forum/#!msg/android-ndk/lcnwzszrESo/wYpPk5BNC-QJ

"the limit is actually not imposed on you, because it is only on the
Java heap.  There is no limit on allocations in the native heap..."

so since Qt on Android runs on the NDK and given how many gigs of RAM
some of these modern devices have, running out of memory seems
unlikely.
but who knows, i think this can be monitored via a task manager.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 8:12 AM, David Tillotson  wrote:
> A quick test of 1059 on the Note 4 (5.1.1), no undo button when deleting.
> Also hit an error that I recall was fixed on the desktop: end pressure higher 
> than start pressure is accepted.

Since I need to get ready to go to the office (running WAY late already), would 
you please file two bugs on this so I can work on them at some point today?

That's the best way to ensure that I remember what needs to get done 

/D

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 8:05 AM, Thomas Pfeiffer  wrote:
> 
> On Thursday, 10 March 2016 22:32:43 CET Dirk Hohndel wrote:
> 
>> I'm sure there are dozens more formats that we could parse. Fundamentally we
>> need a date and time picker control for QML (but I haven't been able to
>> find either). 
> 
> I just talked to Marco about this. There is a calendar component in 
> QQuickControls with which you could build your own date picker. There is 
> nothing for a time picker, though.
> 
> I was able to convince him that it would be useful to have date and time 
> pickers in Kirigami at some point. We cannot promise /when/ they will be 
> available, however.

Thanks, Thomas. We will definitely release with the parsing of a text string 
that
we have right now. Knowing that you guys are working on that is excellent. We'll
simply switch over when you release the date picker. Parsing JUST the time is
much easier, so even having only a date picker would help a lot.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 7:39 AM, Willem Ferguson 
>  wrote:
> 
> On 11/03/2016 16:58, Dirk Hohndel wrote:
>> 
>> I wonder if you are running out of memory. Subsurface (because of the way
>> it is built, and the interaction with git) is a fairly memory hungry
>> application... what phone/tablet is that on? Do you happen to know how
>> much memory that device has?
>> 
>> /D
>> 
> I use a Samsung Galaxy S6 Edge with 32 Gb RAM. I run the software no problem 
> at all on my wife's Galaxy S3 with only 8 Gb RAM.

I'm 99.999% sure that you are talking about the amount of flash in those 
devices, not RAM. I think I've seen reports of 8GB phones, but I don't think 
any ship, yet. Most phones have between 2GB and 4GB RAM these days, some 1GB. 
And it's the 1GB ones where I worry that we might run out of memory.

But on an S6 Edge should have 3GB and definitely not have problems with this.

> But still this does not guarantee that I do not run out of RAM on 5.1.1 
> because who knows how Android 5.1.1 does memory management compared to 
> Android 4.3? On the S3 the mobile app is rock-solid.
> 
> I forgot to mention one thing. On both the S3 and the S6 using build 1058, 
> when I delete a dive the undo button does not appear at all.

I will look into this. Yet another show stopper :-(
Undo really has to work or people will be unhappy.

/D

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread David Tillotson
On 10 March 2016 17:06:01 GMT+00:00, Dirk Hohndel <d...@hohndel.org> wrote:
>After breaking master and the stupidest time possible and subsequently
>fixing it again, I'm planning to make our first release of
>Subsurface-mobile for Android either later today or tomorrow (depending
>a
>bit on how much testing the build that I pushed to the Alpha testers
>this
>morning will get). It's also available in downloads/daily as
>http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1050-release-arm.apk
>
>I updated the user manual based on Willem's excellent work, it can now
>be
>found here:
>
>https://subsurface-divelog.org/documentation/subsurface-mobile-user-manual/
>
>Please read / check the user manual, play with the Android app if you
>have
>access to Android devices and then let's try and get this out the door
>finally.
>
>Thanks
>
>/D
>
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

A quick test of 1059 on the Note 4 (5.1.1), no undo button when deleting.
Also hit an error that I recall was fixed on the desktop: end pressure higher 
than start pressure is accepted.
-- 
David Tillotson
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 7:35 AM, Thomas Pfeiffer  wrote:
> 
> On Friday, 11 March 2016 06:58:17 CET Dirk Hohndel wrote:
> 
>>> Scroll to bottom of dive list.
>>> * Same problem as previously reported: parts of screen is white.
>>> This is worse if one scrolls rapidly.
>> 
>> This is either a QML problem or a Kirigami problem. We have nothing in our
>> code that impacts how this is shown. We need to talk to the QML experts
>> about this, but their responses so far to our other report aren't
>> encouraging.
> 
> What exactly is the problem? Does it not draw the content fast enough while 
> scrolling? Or is it about blank space at the very end of the list?

When I said "QML experts" here I actually didn't point at you or Marco but
at the Qt/QML maintainers (whose response to the reproducible crash in
Qt 5.6 has been a wee bit disappointing). Just so you don't feel like you were
being attacked here...

The problem here, specifically, is that under some circumstances when you
scroll down the divelist suddenly some of the elements will be just blank white
and if you scroll around enough you can get the whole screen to be white.
But then slowly scrolling back a bit repopulates things.

It's kinda hard to describe.

/D

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Thomas Pfeiffer
On Thursday, 10 March 2016 22:32:43 CET Dirk Hohndel wrote:

> I'm sure there are dozens more formats that we could parse. Fundamentally we
> need a date and time picker control for QML (but I haven't been able to
> find either). 

I just talked to Marco about this. There is a calendar component in 
QQuickControls with which you could build your own date picker. There is 
nothing for a time picker, though.

I was able to convince him that it would be useful to have date and time 
pickers in Kirigami at some point. We cannot promise /when/ they will be 
available, however.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Miika Turkia
On Fri, Mar 11, 2016 at 5:39 PM, Willem Ferguson
 wrote:
> On 11/03/2016 16:58, Dirk Hohndel wrote:
>>
>>
>> I wonder if you are running out of memory. Subsurface (because of the way
>> it is built, and the interaction with git) is a fairly memory hungry
>> application... what phone/tablet is that on? Do you happen to know how
>> much memory that device has?
>>
>> /D
>>
> I use a Samsung Galaxy S6 Edge with 32 Gb RAM. I run the software no problem
> at all on my wife's Galaxy S3 with only 8 Gb RAM. But still this does not
> guarantee that I do not run out of RAM on 5.1.1 because who knows how
> Android 5.1.1 does memory management compared to Android 4.3? On the S3 the
> mobile app is rock-solid.
>
> I forgot to mention one thing. On both the S3 and the S6 using build 1058,
> when I delete a dive the undo button does not appear at all.

---8<---
I/DEBUG   ( 2945): pid: 11340, tid: 11386, name: QtThread  >>>
org.subsurfacedivelog.mobile <<<
E/lowmemorykiller( 2928): Error writing /proc/11340/oom_score_adj; errno=22
---8<---

Smells like out of memory to me. I suspect that you mix available
storage with amount of RAM. A quick googling states that Galaxy S3 has
1GB of RAM.

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


Re: Subsurface-mobile for Android first release - images

2016-03-11 Thread Willem Ferguson
>From phone. You cleaned it up the images server side some time ago. Judging
from download times the images are not in server. I have really many
images. However,  if I download the log from cloud,  all the image
references are intact and I can access all images provide I have not moved
them. A really cool arrangement. I hope this answers question.
Kind regards,
Willem
On 11 Mar 2016 5:15 PM, "Dirk Hohndel"  wrote:

>
> > On Mar 11, 2016, at 6:32 AM, Willem Ferguson <
> willemfergu...@zoology.up.ac.za> wrote:
> >
> > Attached logcat. I understand way too little to distinguish between a
> malloc that fails or a malloc based on a pointer that points to the wrong
> place.
>
>
> There appears to be a SIGSEGV in cache_pictures() -- do you still have
> pictures in your git storage? I thought you said you followed Miika's
> instructions and cleaned up the git storage... but of course it could just
> be references to local pictures which the phone can't find - but that
> shouldn't cause us to crash.
>
> /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 for Android first release

2016-03-11 Thread Willem Ferguson

On 11/03/2016 16:58, Dirk Hohndel wrote:


I wonder if you are running out of memory. Subsurface (because of the way
it is built, and the interaction with git) is a fairly memory hungry
application... what phone/tablet is that on? Do you happen to know how
much memory that device has?

/D

I use a Samsung Galaxy S6 Edge with 32 Gb RAM. I run the software no 
problem at all on my wife's Galaxy S3 with only 8 Gb RAM. But still this 
does not guarantee that I do not run out of RAM on 5.1.1 because who 
knows how Android 5.1.1 does memory management compared to Android 4.3? 
On the S3 the mobile app is rock-solid.


I forgot to mention one thing. On both the S3 and the S6 using build 
1058, when I delete a dive the undo button does not appear at all.


Kind regards,
willem


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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 6:58 AM, Dirk Hohndel  wrote:
>> * I gave the GPS part of the software a thorough test during the
>> last two weeks of diving (but not using this very latest version of
>> Subsurface-mobile). But the bugs reported then still remain. Times of GPS
>> fixes are not parsed correctly, resulting in a semi-ordered list with early
>> dives (07h00-09h00) ABOVE more recent dives (10h00-16h00). What about using
>> 24h time notation rather than am/pm?
> 
> That seems reasonable. I thought the sort was already using raw date
> (i.e., the monotonic time_t value) but I need to doublle check that.

We have that role, but explicitly asked to sort by the string.
Fix pushed and new Android APK is being processed (-1059)

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Thomas Pfeiffer
On Friday, 11 March 2016 06:58:17 CET Dirk Hohndel wrote:

> > Scroll to bottom of dive list.
> > * Same problem as previously reported: parts of screen is white.
> > This is worse if one scrolls rapidly.
> 
> This is either a QML problem or a Kirigami problem. We have nothing in our
> code that impacts how this is shown. We need to talk to the QML experts
> about this, but their responses so far to our other report aren't
> encouraging.

What exactly is the problem? Does it not draw the content fast enough while 
scrolling? Or is it about blank space at the very end of the list?
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel

> On Mar 11, 2016, at 6:32 AM, Willem Ferguson 
>  wrote:
> 
> Attached logcat. I understand way too little to distinguish between a malloc 
> that fails or a malloc based on a pointer that points to the wrong place.


There appears to be a SIGSEGV in cache_pictures() -- do you still have pictures 
in your git storage? I thought you said you followed Miika's instructions and 
cleaned up the git storage... but of course it could just be references to 
local pictures which the phone can't find - but that shouldn't cause us to 
crash.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel
On Fri, Mar 11, 2016 at 02:44:41PM +0200, Willem Ferguson wrote:
> Test of version 4.5.2.1058 on Android 5.1.1
> 
> Remove existing app and all data.
> Raw install from Playstore. ok.
> Supply credentials. ok.
> Load divelist from cloud. ok. Quite acceptable speed, around 10 seconds for
> 212 dives.

Yay!

> Scroll to bottom of dive list.
> * Same problem as previously reported: parts of screen is white.
> This is worse if one scrolls rapidly.

This is either a QML problem or a Kirigami problem. We have nothing in our
code that impacts how this is shown. We need to talk to the QML experts
about this, but their responses so far to our other report aren't
encouraging.

> Scroll among dives in Details view. ok.
> View dive location on Google Maps. ok.
> Create dive by hand and save. ok
> * Having checked "Use current GPS location" for this manually-added
> dive, the dive site name is not underlined in the details view and one
> cannot check the location on Google maps. However, the location is recorded
> as I can see the location after loading the dive list from mobile via cloud
> onto the desktop version.

That's odd. There is a bit of a timing issue with the "add dive manually /
use current GPS location" feature. The problem is that if you try this
inside, at your desk, and just fill in some fake data, being inside makes
the GPS accuisition very slow and just adding random data (or very little
data) makes you finish the interaction fairly quckly, so for me often
there was no fix by the time we tried to commit the data.

When you are outside, at a dive site / on a dive boat, the fix acquisition
should be very quick and if you add actual information that should take
long enough.

But from what you say you did get a fix, it just wasn't marked as such.
Hmm. I'll stare at the code and see if there's something obviously wrong,
but this isn't something I'd hold the release for.

> Details view of newly-created dive otherwise ok.
> Scroll horizontally among detail views of dives ok.
> Save dive list to cloud. ok.
> Download dive list from cloud onto desktop version ok, can see manually
> added dive, including coordinates.
> Delete manually-added dive from mobile app. ok.
> Download GPS fixes from cloud ok.
> View list of GPS fixes ok, except see comments below.
> Delete GPS fix ok.

Your test was exhaustive. Thank you for that, Willem. Really appreciated.

> View location of GPS fix on Google Maps ok.
> * I gave the GPS part of the software a thorough test during the
> last two weeks of diving (but not using this very latest version of
> Subsurface-mobile). But the bugs reported then still remain. Times of GPS
> fixes are not parsed correctly, resulting in a semi-ordered list with early
> dives (07h00-09h00) ABOVE more recent dives (10h00-16h00). What about using
> 24h time notation rather than am/pm?

That seems reasonable. I thought the sort was already using raw date
(i.e., the monotonic time_t value) but I need to doublle check that.

> Secondly, GPS coordinates are rounded
> to three digits, when downloading, thus losing three digits of accuracy on
> the original GPS fixes.

I have tried really hard to find where we do this. And I can't seem to
figure it out. I did a fake dive trip with my car and all of the fixes
seemed to be spot on with no lost precision. I continue to be baffled by
this.

> In general, there is still the problem of starting Subsurface-mobile on
> Android 5.1.1, most of the time it crashes but its starts ok on the
> 3rd/4th/5th try. It seems to help if one first kills all the existing
> running apps, found when one taps the bottom-left system button of the
> Android 5.1.1 device and one kills all windows of previously-active apps.
> This is after closing Subsurface-mobile by hitting "Back" while the dive
> list is shown (I hope I make sense). So maybe this is a system interaction.
> Will it help when Subsurface-mobile is closed, to make sure it is really
> killed? But I nevertheless get no easily-repeatable procedure for activating
> the app in a reliable way. I just mention these things in the hope that it
> may lead someone with lateral vision to see the source of this crash.

I wonder if you are running out of memory. Subsurface (because of the way
it is built, and the interaction with git) is a fairly memory hungry
application... what phone/tablet is that on? Do you happen to know how
much memory that device has?

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Willem Ferguson

On 11/03/2016 15:52, Miika Turkia wrote:




On 11 Mar 2016, at 14:44, Willem Ferguson <willemfergu...@zoology.up.ac.za> 
wrote:

In general, there is still the problem of starting Subsurface-mobile on Android 5.1.1, 
most of the time it crashes but its starts ok on the 3rd/4th/5th try. It seems to help if 
one first kills all the existing running apps, found when one taps the bottom-left system 
button of the Android 5.1.1 device and one kills all windows of previously-active apps. 
This is after closing Subsurface-mobile by hitting "Back" while the dive list 
is shown (I hope I make sense). So maybe this is a system interaction. Will it help when 
Subsurface-mobile is closed, to make sure it is really killed? But I nevertheless get no 
easily-repeatable procedure for activating the app in a reliable way. I just mention 
these things in the hope that it may lead someone with lateral vision to see the source 
of this crash.

Have you been able to run logcat? Any change you run out of memory?

miika

Miika,

Attached logcat. I understand way too little to distinguish between a 
malloc that fails or a malloc based on a pointer that points to the 
wrong place.


Kind regards,
willem



logcat.dat.tar.gz
Description: application/gzip
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Dirk Hohndel
On Fri, Mar 11, 2016 at 11:26:05AM +, John Smith wrote:
> > 
> > Miika knows this feeling. Quick question that I forgot to ask earlier. Do
> > you have pictures stored in your dive log by any chance? For a while we
> > stored pictures in the git repository and that can make the repository
> > HUGE. Which would explain why things are so horribly slow.
> > 
> > But I also know that under certain network conditions we do a very poor
> > job, performance wise. Which is disappointing since normally git is a very
> > efficient protocol.
> > 
> I used to have photos but I deleted them after the initial reports of 
> problems. Nothing shows in my desktop but the android file size is massive. 

Ah. Please follow the steps that Miika outlined. If that is not something
you're comfortable with, let me know and I can do part of this on the
server side and make things easier for you.

> >>> Add manual dive - can change time but not date, other than that 
> >>> everything works as expected.
> >> 
> >> What exactly do you mean by "not the date". I tested this several times, 
> >> my blind guess is that you somehow ended up with something that the 
> >> program doesn't parse correctly. The parsing is still a little too picky 
> >> for my taste :-(
> > 
> > I tried a few edits and they all work for me. So a specific example would
> > be good.
> > 
> I used a fairly standard uk dd/mm/ . I tried various permutations on this 
> - essentially trying to replicate the date as shown,but not using the - or . 
> Separators.  Now I know the format it all works.

Well, the problem was that you had to match the previous format fairly
closely. It's still not as flexible as I'd like. And as I said earlier, I
think the right solution is a date and time picker control.

> >>> It's noticeable that although the access cloud warning has disappeared, 
> >>> the app is still thinking and everything is locked out until this process 
> >>> completes.
> >> 
> >> Yes, the notice times out before the access is finished. Maybe that's not 
> >> ideal. THIS is something we could change quite easily.
> > 
> > I just implemented that.
> 
> I'm just playing with that. If I manually upload to the cloud, the accessing 
> cloud bar appears behind the still open manage dive menu. It might be worth 
> changing the display order for the cloud bar to top, or, possibly more 
> difficult, shutting the menu first before starting the upload. But in normal 
> startup etc it works well.

We now have two interaction flows where for some people the notification
is behind a menu. I'll try to figure out if I can force menus closed before
showing the notification...

> > You don't need to file bugs for the three things I mentioned as
> > "Tomaz/Dirk are working on it". But do file a bug on the "editing a date"
> > issue, ideally with an example.
> > And on adding a cylinder from Subsurface-mobile

We should at least file bugs on those two. As I said before, the date
editing needs to be addressed, and we need a solution for the cylinder
input.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Miika Turkia


> On 11 Mar 2016, at 14:44, Willem Ferguson <willemfergu...@zoology.up.ac.za> 
> wrote:
> 
> In general, there is still the problem of starting Subsurface-mobile on 
> Android 5.1.1, most of the time it crashes but its starts ok on the 
> 3rd/4th/5th try. It seems to help if one first kills all the existing running 
> apps, found when one taps the bottom-left system button of the Android 5.1.1 
> device and one kills all windows of previously-active apps. This is after 
> closing Subsurface-mobile by hitting "Back" while the dive list is shown (I 
> hope I make sense). So maybe this is a system interaction. Will it help when 
> Subsurface-mobile is closed, to make sure it is really killed? But I 
> nevertheless get no easily-repeatable procedure for activating the app in a 
> reliable way. I just mention these things in the hope that it may lead 
> someone with lateral vision to see the source of this crash.

Have you been able to run logcat? Any change you run out of memory?

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Miika Turkia
On Fri, Mar 11, 2016 at 1:26 PM, John Smith  wrote:
>
 App informs the user that the cloud is being accessed and it's downloading 
 the dive list - that was 15 minutes ago.  Restarted the app and it took 
 approximately 10 minutes to download a 60 dive database.
>>>
>>> That is stunning. I load 420 dives in maybe 40 seconds. Or a different user 
>>> with 50 dives in maybe 15 seconds.
>>
>> Miika knows this feeling. Quick question that I forgot to ask earlier. Do
>> you have pictures stored in your dive log by any chance? For a while we
>> stored pictures in the git repository and that can make the repository
>> HUGE. Which would explain why things are so horribly slow.
>>
>> But I also know that under certain network conditions we do a very poor
>> job, performance wise. Which is disappointing since normally git is a very
>> efficient protocol.
>>
> I used to have photos but I deleted them after the initial reports of 
> problems. Nothing shows in my desktop but the android file size is massive.

yep, the the photos are still stored on the git repository, even
though you cannot see them directly in Subsurface. And therefor the
size of your cloud data is massive when comparing to what it could be.
I resolved my issue by forcing new (empty) git history into the cloud
with following steps:

Using star in the commands assumes that there is only one directory
under cloudstorage, which should be the normal case.

$ cd ~/.subsurface/cloudstorage/*
$ git checkout --orphan force
$ git add -A
$ git commit
$ git branch  -D miika.tur...@gmail.com
$ git branch -m miika.tur...@gmail.com
$ git push -u --force origin miika.tur...@gmail.com
$ cd .. && rm -rf *

* And finally open up the cloud storage on Subsurface desktop application.


The above assumes you are on Linux machine, but the git steps should
be the same on other OSes. You basically create an orphaned branch
with only one git commit that contains your current log book. Then you
replace the master branch with this clean branch, and force push it
all to the cloud storage overwriting the old data. This cleaned a few
hundred megs from my repository allowing fast syncs after these steps.
Obviously you will need to tune some info on the commands and
hopefully have some understanding of what you are doing, if you want
to clean the cloud storage with this method.

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Willem Ferguson

Test of version 4.5.2.1058 on Android 5.1.1

Remove existing app and all data.
Raw install from Playstore. ok.
Supply credentials. ok.
Load divelist from cloud. ok. Quite acceptable speed, around 10 seconds 
for 212 dives.

Scroll to bottom of dive list.
* Same problem as previously reported: parts of screen is white. 
This is worse if one scrolls rapidly.

Scroll among dives in Details view. ok.
View dive location on Google Maps. ok.
Create dive by hand and save. ok
* Having checked "Use current GPS location" for this 
manually-added dive, the dive site name is not underlined in the details 
view and one cannot check the location on Google maps. However, the 
location is recorded as I can see the location after loading the dive 
list from mobile via cloud onto the desktop version.

Details view of newly-created dive otherwise ok.
Scroll horizontally among detail views of dives ok.
Save dive list to cloud. ok.
Download dive list from cloud onto desktop version ok, can see manually 
added dive, including coordinates.

Delete manually-added dive from mobile app. ok.
Download GPS fixes from cloud ok.
View list of GPS fixes ok, except see comments below.
Delete GPS fix ok.
View location of GPS fix on Google Maps ok.
* I gave the GPS part of the software a thorough test during the 
last two weeks of diving (but not using this very latest version of 
Subsurface-mobile). But the bugs reported then still remain. Times of 
GPS fixes are not parsed correctly, resulting in a semi-ordered list 
with early dives (07h00-09h00) ABOVE more recent dives (10h00-16h00). 
What about using 24h time notation rather than am/pm? Secondly, GPS 
coordinates are rounded to three digits, when downloading, thus losing 
three digits of accuracy on the original GPS fixes.


In general, there is still the problem of starting Subsurface-mobile on 
Android 5.1.1, most of the time it crashes but its starts ok on the 
3rd/4th/5th try. It seems to help if one first kills all the existing 
running apps, found when one taps the bottom-left system button of the 
Android 5.1.1 device and one kills all windows of previously-active 
apps. This is after closing Subsurface-mobile by hitting "Back" while 
the dive list is shown (I hope I make sense). So maybe this is a system 
interaction. Will it help when Subsurface-mobile is closed, to make sure 
it is really killed? But I nevertheless get no easily-repeatable 
procedure for activating the app in a reliable way. I just mention these 
things in the hope that it may lead someone with lateral vision to see 
the source of this crash.


Kind regards,
willem





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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread John Smith


Sent from my iPad

> On 11 Mar 2016, at 02:11, Dirk Hohndel  wrote:
> 
> After some more thinking and discussing things with Tomaz over dinner I
> decided to in fact address the easier ones of these and delay the release
> by a day or two for this.
> 
> On Thu, Mar 10, 2016 at 04:53:56PM -0800, Dirk Hohndel wrote:
>>> 
>>> App opens to the login page. Straight forward entering details and doing a 
>>> credential check. It might be an idea to change the font colour on the 
>>> status messages as they don't standout at all. Maybe red for error messages?
>> 
>> Good idea.

Much easier to see now.
> Tomaz is working on this right now.
>> 
>>> App informs the user that the cloud is being accessed and it's downloading 
>>> the dive list - that was 15 minutes ago.  Restarted the app and it took 
>>> approximately 10 minutes to download a 60 dive database.
>> 
>> That is stunning. I load 420 dives in maybe 40 seconds. Or a different user 
>> with 50 dives in maybe 15 seconds.
> 
> Miika knows this feeling. Quick question that I forgot to ask earlier. Do
> you have pictures stored in your dive log by any chance? For a while we
> stored pictures in the git repository and that can make the repository
> HUGE. Which would explain why things are so horribly slow.
> 
> But I also know that under certain network conditions we do a very poor
> job, performance wise. Which is disappointing since normally git is a very
> efficient protocol.
> 
I used to have photos but I deleted them after the initial reports of problems. 
Nothing shows in my desktop but the android file size is massive. 
>>> Add manual dive - can change time but not date, other than that everything 
>>> works as expected.
>> 
>> What exactly do you mean by "not the date". I tested this several times, my 
>> blind guess is that you somehow ended up with something that the program 
>> doesn't parse correctly. The parsing is still a little too picky for my 
>> taste :-(
> 
> I tried a few edits and they all work for me. So a specific example would
> be good.
> 
I used a fairly standard uk dd/mm/ . I tried various permutations on this - 
essentially trying to replicate the date as shown,but not using the - or . 
Separators.  Now I know the format it all works.
>>> Can't see what the gas mix does as it only ever seems to show air and I 
>>> can't change it to anything that seems sensible I.e. Nitrox 32 or 15/40 
>>> trimix etc. It might be better to remove it from the edit list for now.
>> 
>> That would mean delaying the first release. I'll mark it as a "known issue". 
>> That's annoying - it's something I never tested... which is why it's so 
>> important to have testers try all the different parts of an app... I spend 
>> way too much time on the mechanics of getting this all to work that I 
>> usually am not thorough enough when testing. As seen here.
>> Definitely something we want to fix for v1.1
> 
Now showing correctly as eanXX
> Actually, something we want to fix for 1.0. Tomaz is looking into that one
> as well.
> 
>>> Dive details show cylinder information but you can't add cylinders. Not a 
>>> problem, but worth noting.
>> 
>> Dang - both this and the previous issue could have been easily noticed and 
>> fixed in the long beta cycle :-(
> 
> This is not something we can fix over night, so this will have to wait for
> the next release.
> 
>>> Uploading new dive to cloud was equally slow and painful, followed 
>>> immediate after by a crash
>> 
>> The slow I don't understand, the crash worries me. I test this particular 
>> part of the app (editing things, adding things, deleting things and syncing 
>> with the cloud) all the time.
>> You don't happen to have a stack trace or anything from the logcat?
Sorry, no. I'm not overly familiar with android, I only bought one to play with 
subsurface! Where would the logcat output get stored?
>> 
>>> Can't see new dive on desktop version - although developer log says 61 
>>> dives on cloud which should be correct - possible bug in desktop? No, after 
>>> clearing memory and reloading, the dive doesn't reappear indicating that 
>>> the cloud wasn't correctly updated.
>> 
>> The crash might have prevented this from working. Again, this works really 
>> reliably for me. Are you connecting over wifi? Or via 3G/LTE? Or GPRS? :-)
>> 
Wifi
>>> Try again. Worked this time.
>> 
>> Good.
>> 
>>> It's noticeable that although the access cloud warning has disappeared, the 
>>> app is still thinking and everything is locked out until this process 
>>> completes.
>> 
>> Yes, the notice times out before the access is finished. Maybe that's not 
>> ideal. THIS is something we could change quite easily.
> 
> I just implemented that.

I'm just playing with that. If I manually upload to the cloud, the accessing 
cloud bar appears behind the still open manage dive menu. It might be worth 
changing the display order for the cloud bar to top, or, possibly more 
difficult, shutting the menu first before 

RE: Subsurface-mobile for Android first release

2016-03-11 Thread Steve
And one more response to my own email...

Subsurface-mobile 1.0.1 (4.5.2.1058) is available in downloads/daily and on its 
way to both alpha and beta testers.


Just installed the 1.0.1 version.
I was going to report that on the last install 1.0.0 that it showed 
accessing cloud storage, then it showed the credentials screen for a short 
while (even though it was an update and my credentials were in and unchanged) 
and then it went to showing the dive list.
I was also going to report that while on the GPS fixes screen swiping 
left and right sometimes would leave a small portion on the left hand side of 
the other/previous screen view
After some more quick testing both of these issues seem to be fixed in 
1.0.1.

I did find that if I scrolled right to the very bottom of the dive list 
that I end up with a white blank screen or the first dive or first couple of 
dives missing with white space below the first shown dive.
Not the end of the world just slightly strange.

 I also read the online manual because I was curious about how the GPS 
fixes are sorted. I think it could be useful to have the manual as part of the 
program opening up in a browser window?
When testing I created a new GPS fix then found it hard to locate that 
dummy GPS fix to be able to delete it.

It has come a long way and is very usable, great work all!



While I wish that some of this had been found earlier, I'm very happy that 
these things were found before a public release. Yes, the red texts are a user 
visible change and in theory one screen shot in the manual should be changed. 
But I really am not worried about this. All of the changes are making 
Subsurface-mobile 1.0.1 a much stronger release so I'm very grateful that this 
feedback came in just in time.

Please, please, please: MORE TESTING. Yes, I'd love to release tomorrow. But 
I'd even more like to fix any other unpleasant surprises before hundreds of 
users play with it and run into bugs that we could have fixed before the 
release.

Thanks everyone for all your hard work so far. We are really, really close!

/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 for Android first release

2016-03-11 Thread Jan Mulder

On 11-03-16 09:35, Salvador Cuñat wrote:


Hi Dirk.

El 11/03/2016 07:32, "Dirk Hohndel" > escribió:

>
> And one more response to my own email...
>
> Subsurface-mobile 1.0.1 (4.5.2.1058) is available in downloads/daily 
and on its way to both alpha and beta testers.

>

The cancel delete item isn't there for me.
So delete action can't be reversed.

I'm on android 4.3 with Google 1.0.1

Regards.

Salva.



Same here. Delete does work correctly, but the menu drawer stays open 
for the undo timeout period (it seems), and then a tiny flash with the 
undo button, which is (obviously) to short to hit it.


Latest CyanogenMod 6.0.1 nightly.

best,

--jan

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


Re: Subsurface-mobile for Android first release

2016-03-11 Thread Salvador Cuñat
Hi Dirk.

El 11/03/2016 07:32, "Dirk Hohndel"  escribió:
>
> And one more response to my own email...
>
> Subsurface-mobile 1.0.1 (4.5.2.1058) is available in downloads/daily and
on its way to both alpha and beta testers.
>

The cancel delete item isn't there for me.
So delete action can't be reversed.

I'm on android 4.3 with Google 1.0.1

Regards.

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


Re: Subsurface-mobile for Android first release

2016-03-10 Thread Dirk Hohndel
And one more response to my own email...

Subsurface-mobile 1.0.1 (4.5.2.1058) is available in downloads/daily and on its 
way to both alpha and beta testers.

> On Mar 10, 2016, at 6:10 PM, Dirk Hohndel  wrote:
>>> 
>>> App opens to the login page. Straight forward entering details and doing a 
>>> credential check. It might be an idea to change the font colour on the 
>>> status messages as they don't standout at all. Maybe red for error messages?
>> 
>> Good idea.
> 
> Tomaz is working on this right now.

This is in 1.0.1

>>> Add manual dive - can change time but not date, other than that everything 
>>> works as expected.
>> 
>> What exactly do you mean by "not the date". I tested this several times, my 
>> blind guess is that you somehow ended up with something that the program 
>> doesn't parse correctly. The parsing is still a little too picky for my 
>> taste :-(
> 
> I tried a few edits and they all work for me. So a specific example would
> be good.

The code is now much more flexible and understands a lot more date formats. 
2016-3-10 14:34 (for our ISO friends). 3/10/16 2:34pm (for the Americans). 
10.3.2016 14:34:30 (for the Germans with second precision). All of the 
variations support 4 digit and two digit year. With and with seconds. And for 
the American format we support both 24h and am/pm time.

I'm sure there are dozens more formats that we could parse. Fundamentally we 
need a date and time picker control for QML (but I haven't been able to find 
either). But for now this should be a substantial improvement.

>>> Can't see what the gas mix does as it only ever seems to show air and I 
>>> can't change it to anything that seems sensible I.e. Nitrox 32 or 15/40 
>>> trimix etc. It might be better to remove it from the edit list for now.
>> 
>> That would mean delaying the first release. I'll mark it as a "known issue". 
>> That's annoying - it's something I never tested... which is why it's so 
>> important to have testers try all the different parts of an app... I spend 
>> way too much time on the mechanics of getting this all to work that I 
>> usually am not thorough enough when testing. As seen here.
>> Definitely something we want to fix for v1.1
> 
> Actually, something we want to fix for 1.0. Tomaz is looking into that one
> as well.

Actually, I found the bug. The parsing was correct, but the validation of the 
result of what we parsed was bogus. We compared permille values to percent 
thresholds (so we added the permille values of o2 and he and checked if they 
were <= 100... :facepalm:)

>>> Dive details show cylinder information but you can't add cylinders. Not a 
>>> problem, but worth noting.
>> 
>> Dang - both this and the previous issue could have been easily noticed and 
>> fixed in the long beta cycle :-(
> 
> This is not something we can fix over night, so this will have to wait for
> the next release.

That's unchanged. That is way more change than I'm willing to do this late

>>> It's noticeable that although the access cloud warning has disappeared, the 
>>> app is still thinking and everything is locked out until this process 
>>> completes.
>> 
>> Yes, the notice times out before the access is finished. Maybe that's not 
>> ideal. THIS is something we could change quite easily.
> 
> I just implemented that.

And found a specific situation in which we showed that we were accessing cloud 
storage when actually we were not.

While I wish that some of this had been found earlier, I'm very happy that 
these things were found before a public release. Yes, the red texts are a user 
visible change and in theory one screen shot in the manual should be changed. 
But I really am not worried about this. All of the changes are making 
Subsurface-mobile 1.0.1 a much stronger release so I'm very grateful that this 
feedback came in just in time.

Please, please, please: MORE TESTING. Yes, I'd love to release tomorrow. But 
I'd even more like to fix any other unpleasant surprises before hundreds of 
users play with it and run into bugs that we could have fixed before the 
release.

Thanks everyone for all your hard work so far. We are really, really close!

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


Re: Subsurface-mobile for Android first release

2016-03-10 Thread John Smith
I started with a fresh installation and no local files.

App opens to the login page. Straight forward entering details and doing a 
credential check. It might be an idea to change the font colour on the status 
messages as they don't standout at all. Maybe red for error messages?

App informs the user that the cloud is being accessed and it's downloading the 
dive list - that was 15 minutes ago.  Restarted the app and it took 
approximately 10 minutes to download a 60 dive database.

Dive list scrolls well and there is only a small lag between clicking on a dive 
and the dive details being shown.

The left and right slides are a little difficult to use until you are used to 
the movement required.

Clicking on the pen opens up the edit window, changes are easy to make and the 
screen returns to the dive window with updated details all correct.

Clicking the dive map correctly opens google map and shows the dive site.

The back button takes me back to the dive list as expected. 

Add manual dive - can change time but not date, other than that everything 
works as expected.

Can't see what the gas mix does as it only ever seems to show air and I can't 
change it to anything that seems sensible I.e. Nitrox 32 or 15/40 trimix etc. 
It might be better to remove it from the edit list for now.

Dive details show cylinder information but you can't add cylinders. Not a 
problem, but worth noting.

Uploading new dive to cloud was equally slow and painful, followed immediate 
after by a crash

Can't see new dive on desktop version - although developer log says 61 dives on 
cloud which should be correct - possible bug in desktop? No, after clearing 
memory and reloading, the dive doesn't reappear indicating that the cloud 
wasn't correctly updated. 

Try again. Worked this time.

It's noticeable that although the access cloud warning has disappeared, the app 
is still thinking and everything is locked out until this process completes.

Made change on desktop, change seen on app after reopening.

Deleted dive ok. The undo is there a little longer than I would like, but 
that's a personal thing. Change replicated on desktop ok.

Overall the app is easy to use and reasonably intuitive. The lag in loading and 
saving is a real bind. It's not a bandwidth issue from my side and the desktop 
version doesn't have the same delays. 

I think that covers most things.

:)











Sent from my iPad

> On 10 Mar 2016, at 17:06, Dirk Hohndel <d...@hohndel.org> wrote:
> 
> After breaking master and the stupidest time possible and subsequently
> fixing it again, I'm planning to make our first release of
> Subsurface-mobile for Android either later today or tomorrow (depending a
> bit on how much testing the build that I pushed to the Alpha testers this
> morning will get). It's also available in downloads/daily as
> http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1050-release-arm.apk
> 
> I updated the user manual based on Willem's excellent work, it can now be
> found here:
> 
> https://subsurface-divelog.org/documentation/subsurface-mobile-user-manual/
> 
> Please read / check the user manual, play with the Android app if you have
> access to Android devices and then let's try and get this out the door
> finally.
> 
> 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-mobile for Android first release

2016-03-10 Thread Dirk Hohndel
After breaking master and the stupidest time possible and subsequently
fixing it again, I'm planning to make our first release of
Subsurface-mobile for Android either later today or tomorrow (depending a
bit on how much testing the build that I pushed to the Alpha testers this
morning will get). It's also available in downloads/daily as
http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.1050-release-arm.apk

I updated the user manual based on Willem's excellent work, it can now be
found here:

https://subsurface-divelog.org/documentation/subsurface-mobile-user-manual/

Please read / check the user manual, play with the Android app if you have
access to Android devices and then let's try and get this out the door
finally.

Thanks

/D

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


Re: Subsurface-mobile for Android -845

2016-02-14 Thread Dirk Hohndel
On Sun, Feb 14, 2016 at 04:05:42PM +0100, Thomas Pfeiffer wrote:
> On Sonntag, 14. Februar 2016 15:52:44 CET Rick Walsh wrote:
> 
> > The logic is good, and the description makes sense.  The reasons I'd rather
> > the action button be 'save' are:
> > (1) I'm lazy and if all I want to do is enter/alter a couple of details
> > (e.g. dive site and buddy), then I don't want to have to scroll down to the
> > bottom of the page to find the save button
> 
> I agree with Rick that the action button has to be "Save and close". Not 
> primarily to accommodate laziness, but because "Save and close" is the 
> primary 
> action when editing something, which is what the button is for.

That has already been implemented in -858

> > (2) we effectively have two quick-access buttons: the action button and the
> > back button.  Having both do the same thing (with or without confirmation)
> > is a bit of a waste.  We have two actions that should be accessed rapidly:
> > save and discard.  The back button can be used to discard changes, so it
> > makes sense to me that the action button would be save.
> 
> Yup, makes sense.

And that's what we have :-)

> > (3) let's trust the user knows what she's doing - more often than not, when
> > the user wants to leave the page, she wants to save changes.  We should
> > make that as easy as possible.
> 
> Would it be technically possible that if the user goes back via the back 
> button but immediately taps the action button again to go back to edit mode, 
> they'd still see their changes? 
> That would mean you'd have to keep the changes in memory until the user goes 
> somewhere else, but it would make us tolerant toward  hitting the back button 
> by accident.

I don't like that. Depending on how quickly you tap the button you get a
fresh edit or the old edit - surprising to the user.

> P.S.: I've subscribed to the mailing list now, so no need to CC me anymore. 
> Please remember to still CC Marco Martin for anything that would be relevant 
> for for the components themselves.

Actually, Marco is on the mailing list as well by now. Looks like we
sucked both of you into working on Subsurface. Thanks for your willingness
to help!

:-)

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Thomas Pfeiffer
On Samstag, 13. Februar 2016 10:35:50 CET Henrik Brautaset Aronsen wrote:
> On Sat, Feb 13, 2016 at 9:59 AM, Henrik Brautaset Aronsen <
> 
> subsurf...@henrik.synth.no> wrote:
> > Just a couple of things: The title bar is too cramped now.  Other apps use
> > that to display info on the current context.  We could display "Dive list"
> > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> > 
> > And since we're going for the action button design, how about making it
> > more like the action buttons in other apps, i.e. larger and more to the
> > right?

+1 for making it bigger (I don't know why it's currently so small, it was 
bigger in our mockups). I wouldn't push it to the side, though, because it can 
still be dragged to open drawers, so the center position is best for that.

Even though Subsurface uses no context drawer at the moment doesn't mean that 
it never will, so I wouldn't recommend optimizing the overall UI for not 
having one

Also, there are some Google apps which have the action button at the center 
(e.g. Phone or Clock), even though most have it on the right.

> And if possible, why not go all in:  It looks like the google apps (e.g.
> Google Plus and Photos) hide the top bar and the action button as you
> scroll downwards in a list (or large page), giving full access to the
> screen estate.

Marco had the idea to hide the top bar when scrolling as well, and it 
absolutely makes sense to me, since people should still remember where they 
are even when they scroll down.
I'm not so sure about the action button, though, given that it holds the most 
important action on a screen.

Cheers,
Thomas (responsible for the KDE mobile HIG)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel
On Sat, Feb 13, 2016 at 09:29:34AM +0100, Joakim Bygdell wrote:
> > 
> > 845 should address the issues that were mentioned
> > 
> > - I think I finally figured out the hang with incorrect credentials
> > - I FINALLY paid enough attention to realize why the 'Save' after an edit 
> > accessed the network - that should be fixed now
> > - the redundant context menus are gone. Android users are comfortable using 
> > the back button to go up / back a level and to cancel an operation
> > 
> > So I think this is the UI direction I'm leaning towards. Small title bar 
> > with no menus / buttons. Action button when there's an action. Handle to 
> > open global menu / drawer (but swipe from the side works as well). Right 
> > now we have no screen that has a context menu.
> The handle that opens the drawer should maybe be a bit more transparent to 
> start with, not the arrow but the background.

Yes, there is definitely some fine tuning to be done here.

> The action button we need to do something with as well, right now you have  
> to scroll all the way to the bottom ft prevent the 
>  action button form obscuring stuff on the details and edit pages.

I find that an interesting comment. Let me try to figure out if I
understand what you are saying: when you are in the middle of the dive
list, the action button is obscuring a small part in the center of the
bottom dive that is visible (assuming you are on a phone or tablet in
portrait mode - in landscape mode it really isn't in the way at all as it
sits on the center divider). So what is stopping you from scrolling up by
one dive to see the dive that you want to see? I don't understand your
refference to "have to scroll all the way to the bottom" of the dive list.
Or are you saying you'd like to have this white margin at the bottom all
the time? Because I'd hate that as wasted screen real estate.

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Joakim Bygdell

> On 13 Feb 2016, at 18:52, Dirk Hohndel  wrote:
> 
> On Sat, Feb 13, 2016 at 09:29:34AM +0100, Joakim Bygdell wrote:
>>> 
>>> 845 should address the issues that were mentioned
>>> 
>>> - I think I finally figured out the hang with incorrect credentials
>>> - I FINALLY paid enough attention to realize why the 'Save' after an edit 
>>> accessed the network - that should be fixed now
>>> - the redundant context menus are gone. Android users are comfortable using 
>>> the back button to go up / back a level and to cancel an operation
>>> 
>>> So I think this is the UI direction I'm leaning towards. Small title bar 
>>> with no menus / buttons. Action button when there's an action. Handle to 
>>> open global menu / drawer (but swipe from the side works as well). Right 
>>> now we have no screen that has a context menu.
>> The handle that opens the drawer should maybe be a bit more transparent to 
>> start with, not the arrow but the background.
> 
> Yes, there is definitely some fine tuning to be done here.
> 
>> The action button we need to do something with as well, right now you have  
>> to scroll all the way to the bottom ft prevent the 
>> action button form obscuring stuff on the details and edit pages.
> 
> I find that an interesting comment. Let me try to figure out if I
> understand what you are saying: when you are in the middle of the dive
> list, the action button is obscuring a small part in the center of the
> bottom dive that is visible (assuming you are on a phone or tablet in
> portrait mode - in landscape mode it really isn't in the way at all as it
> sits on the center divider). So what is stopping you from scrolling up by
> one dive to see the dive that you want to see? I don't understand your
> refference to "have to scroll all the way to the bottom" of the dive list.
> Or are you saying you'd like to have this white margin at the bottom all
> the time? Because I'd hate that as wasted screen real estate.
Not the dive list, but on details and edit page. 

> /D

/Jocke

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel
On Sat, Feb 13, 2016 at 09:59:27AM +0100, Henrik Brautaset Aronsen wrote:
> On Sat, Feb 13, 2016 at 8:07 AM, Dirk Hohndel  wrote:
> >
> > There certainly is room for fine-tuning (I just noticed that the icon /
> > text in the title bar aren't vertically centered - also the drawer handle
> > maybe isn't the final design, yet - this is just my quick hack to give
> > Thomas and Marco an idea of what I'm thinking). But unless I hear strong
> > and well reasoned feedback from Henrik or some of the others who have been
> > rather outspoken on wanting the more Android typical menu / action buttons
> > in the top bar, I think that's where we'll go.
> >
> 
> Hi!  I think it looks pretty decent now.  I like that there is less clutter.

Yay!

> Just a couple of things: The title bar is too cramped now.  Other apps use
> that to display info on the current context.  We could display "Dive list"
> or "Dive #643" or "Edit dive #242" or "About" there in the future.

That's a good idea... but I think I like the idea of it simply fading away
even better.

> And since we're going for the action button design, how about making it
> more like the action buttons in other apps, i.e. larger and more to the
> right?

Thomas answered the "more to the right" question. But there's another
reason. Right now, when you use your device in landscape mode you get the
action button right on the center divider which is perfect, IMHO.

> And one more (less related) thing:  If I edit a dive and press the back
> button (instead of save), I should get a request: "Discard edits? [Yes /
> Save edits / Cancel]

I hate those dialogs on some level, but I guess you are right.

Thomas, what's the HID approved way of doing something like that?

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel
On Sat, Feb 13, 2016 at 06:55:36PM +0100, Joakim Bygdell wrote:
> > 
> >> The action button we need to do something with as well, right now you have 
> >>  to scroll all the way to the bottom ft prevent the 
> >> action button form obscuring stuff on the details and edit pages.
> > 
> Not the dive list, but on details and edit page. 

DUH. You said that right there. So we need to do something similar to be
able to scroll those pages up higher.

Can you file a bug so I don't forget?

Thanks

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Willem Ferguson
I ran 849 on two Android versions 4.3 and 5.1.1. Appears pretty stable, 
especially on Android 4.3. A few points or suggestions, :


1) In Show GPS fixes, the text flows underneath the three lines forming 
the drag point on the right of each GPS record. In 5.1.1 this is worse 
than with 4.3.


2) About the right-hand action panel (context menu?), I would not rule 
it out at this point altogether. For instance after editing, the SAVE 
button at the bottom is located in a little bit of an unexpected place. 
A context menu with SAVE CHANGES and QUIT WITHOUT SAVING could work. Of 
course this creates the question of what the Action Button should do in 
this situation, so I can understand if a context menu is not implemented 
here.


3) Text in the landing screen has a left margin pretty close to the left 
edge of the screen.


4) I have now loaded a full dive log (only some 200 dives) onto both 
mobile devices and I was surprised how rapidly a fairly large data set 
was loaded. After loading these data using 845, however, the program 
unpredictably crashes at startup. Attached a logcat. I would say about 
60% of startups end in a crash. Those that start up behave pretty 
normally, no obvious anomalies. With 849 still the same problem. If 
necessary I can collect more information.


Kind regards,
willem





logcatwf.dat.tar.gz
Description: application/gzip
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Joakim Bygdell

> On 13 Feb 2016, at 08:07, Dirk Hohndel  wrote:
> 
> Hi there.
> 
> 845 should address the issues that were mentioned
> 
> - I think I finally figured out the hang with incorrect credentials
> - I FINALLY paid enough attention to realize why the 'Save' after an edit 
> accessed the network - that should be fixed now
> - the redundant context menus are gone. Android users are comfortable using 
> the back button to go up / back a level and to cancel an operation
> 
> So I think this is the UI direction I'm leaning towards. Small title bar with 
> no menus / buttons. Action button when there's an action. Handle to open 
> global menu / drawer (but swipe from the side works as well). Right now we 
> have no screen that has a context menu.
The handle that opens the drawer should maybe be a bit more transparent to 
start with, not the arrow but the background.

The action button we need to do something with as well, right now you have  to 
scroll all the way to the bottom ft prevent the 
 action button form obscuring stuff on the details and edit pages.

> 
> There certainly is room for fine-tuning (I just noticed that the icon / text 
> in the title bar aren't vertically centered - also the drawer handle maybe 
> isn't the final design, yet - this is just my quick hack to give Thomas and 
> Marco an idea of what I'm thinking). But unless I hear strong and well 
> reasoned feedback from Henrik or some of the others who have been rather 
> outspoken on wanting the more Android typical menu / action buttons in the 
> top bar, I think that's where we'll go.
> 
> I realize that I'm going back and forth on this. Guilty as charged. This is 
> hard. But I spent almost an hour with a 4" phone, a 5.7" phone, a 7" tablet 
> and a 10" tablet and I think I'm happy with what we have.
> 
> Assuming we can get reasonable consensus (or only mostly unconvincing 
> whining), I'll do a second beta based on this UI idea (after Marco helps me 
> with the fine tuning mentioned above).
> 
> Thoughts? Comments?
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

/Jocke

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Henrik Brautaset Aronsen
On Sat, Feb 13, 2016 at 9:59 AM, Henrik Brautaset Aronsen <
subsurf...@henrik.synth.no> wrote:

>
> Just a couple of things: The title bar is too cramped now.  Other apps use
> that to display info on the current context.  We could display "Dive list"
> or "Dive #643" or "Edit dive #242" or "About" there in the future.
>
> And since we're going for the action button design, how about making it
> more like the action buttons in other apps, i.e. larger and more to the
> right?
>

And if possible, why not go all in:  It looks like the google apps (e.g.
Google Plus and Photos) hide the top bar and the action button as you
scroll downwards in a list (or large page), giving full access to the
screen estate.

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Henrik Brautaset Aronsen
On Sat, Feb 13, 2016 at 8:07 AM, Dirk Hohndel  wrote:

> Hi there.
>
> There certainly is room for fine-tuning (I just noticed that the icon /
> text in the title bar aren't vertically centered - also the drawer handle
> maybe isn't the final design, yet - this is just my quick hack to give
> Thomas and Marco an idea of what I'm thinking). But unless I hear strong
> and well reasoned feedback from Henrik or some of the others who have been
> rather outspoken on wanting the more Android typical menu / action buttons
> in the top bar, I think that's where we'll go.
>

Hi!  I think it looks pretty decent now.  I like that there is less clutter.

Just a couple of things: The title bar is too cramped now.  Other apps use
that to display info on the current context.  We could display "Dive list"
or "Dive #643" or "Edit dive #242" or "About" there in the future.

And since we're going for the action button design, how about making it
more like the action buttons in other apps, i.e. larger and more to the
right?

And one more (less related) thing:  If I edit a dive and press the back
button (instead of save), I should get a request: "Discard edits? [Yes /
Save edits / Cancel]

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Thomas Pfeiffer
On Samstag, 13. Februar 2016 09:57:21 CET Dirk Hohndel wrote:
> > Hi!  I think it looks pretty decent now.  I like that there is less
> > clutter.
> Yay!

Yay++

> > Just a couple of things: The title bar is too cramped now.  Other apps use
> > that to display info on the current context.  We could display "Dive list"
> > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> 
> That's a good idea... but I think I like the idea of it simply fading away
> even better.

+1 for fading away.

> > And since we're going for the action button design, how about making it
> > more like the action buttons in other apps, i.e. larger and more to the
> > right?
> 
> Thomas answered the "more to the right" question. But there's another
> reason. Right now, when you use your device in landscape mode you get the
> action button right on the center divider which is perfect, IMHO.
> 
> > And one more (less related) thing:  If I edit a dive and press the back
> > button (instead of save), I should get a request: "Discard edits? [Yes /
> > Save edits / Cancel]
> 
> I hate those dialogs on some level, but I guess you are right.
 
> Thomas, what's the HID approved way of doing something like that?

We originally had the idea that for "swipe to go back/forward" or "column-
based navigation", one could simply swipe forward again to get back to the 
already entered/changed data if one has accidentally swiped back without 
saving (before navigating somewhere else). That's not as easily possible when 
using the back button, of course.

Google's apps for Android (those which do not auto-save) do use such a dialog. 
They all use a Discard/Cancel approach (though with completely different 
wording and even inconsistent button position between the apps, which is 
really bad design).
We haven't written about it in the HIG yet (we'll still add one guideline for 
that), but here's what I'd suggest:
"Discard your changes?" [Discard] [Keep Editing]". This makes saving take one 
more step, but we want to train users to just hit "Save" anyway, and it makes 
the decision in the dialog easier.
There is already a component for a slide-in dialog available (don't know its 
name, though, tbh. If you can't find it, ask Marco).

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel

> On Feb 13, 2016, at 8:52 PM, Rick Walsh  wrote:
> > Another thing - In the dive list, there's a blank row above the trip
> > separator line.  I'm not sure if that's deliberate, but it looks like a
> > waste of space to me.
> 
> Do you have a screen shot?
> 
> See attached
>  

Those blank rows are the trip titles...

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel
On Sun, Feb 14, 2016 at 03:52:44PM +1100, Rick Walsh wrote:
> > So I tried to implement something that I find reasonable and intuitive.
> >
> > - there's still the save button
> > - the action button is cancel and there is NO CONFIRMATION - you hit that
> >   button, you get what you asked for
> > - the back button asks the user if they really wanted to discard the
> >   changes, and if they don't confirm within 3 seconds it simply hides the
> >   confirmation dialog and pretends nothing happens
> >
> > Please play with it, the description sounds a lot more awkward that it
> > felt to me to use...
> >
> 
> The logic is good, and the description makes sense.  The reasons I'd rather
> the action button be 'save' are:
> (1) I'm lazy and if all I want to do is enter/alter a couple of details
> (e.g. dive site and buddy), then I don't want to have to scroll down to the
> bottom of the page to find the save button
> (2) we effectively have two quick-access buttons: the action button and the
> back button.  Having both do the same thing (with or without confirmation)
> is a bit of a waste.  We have two actions that should be accessed rapidly:
> save and discard.  The back button can be used to discard changes, so it
> makes sense to me that the action button would be save.
> (3) let's trust the user knows what she's doing - more often than not, when
> the user wants to leave the page, she wants to save changes.  We should
> make that as easy as possible.

I can see your point. So let me rip out the work that I did and implement
that instead.

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel

> On Feb 13, 2016, at 10:33 PM, Willem Ferguson 
>  wrote:
> 
> On 14/02/2016 06:18, Dirk Hohndel wrote:
>> On Sat, Feb 13, 2016 at 09:59:36PM +0200, Willem Ferguson wrote:
>>> I ran 849 on two Android versions 4.3 and 5.1.1. Appears pretty stable,
>>> especially on Android 4.3. A few points or suggestions, :
>>> 
>>> 1) In Show GPS fixes, the text flows underneath the three lines forming the
>>> drag point on the right of each GPS record. In 5.1.1 this is worse than with
>>> 4.3.
>> I think this is more a font-size to screen-size issue than a 4.3 vs 5.1.1
>> issue. Do you have a screen shot?
>> 
> Attached

As expected. Font size. I wonder why the fonts on your device are so big,
relatively speaking. Do you have any overall Android settings that would
increase the default font size? I'd hate to have to add some heuristics that
would make us shrink the fonts for certain ratios of font size and screen 
width...

/D

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Dirk Hohndel
On Sun, Feb 14, 2016 at 03:12:11PM +1100, Rick Walsh wrote:
> I just tested 849.  I think the use of the action button is very good.  It
> doesn't waste space, it's transparent enough not to be invasive, it's easy
> to reach, and most importantly, the icons give good clues what the button
> does (unlike the original action button, which was powerful, efficient use
> of space, but confusing to many the first time they saw it).  I also like
> that I can still/again swipe the central action button instead of using the
> arrows - as I said before, when holding my phone in my not-dainty left
> hand, reaching the very left bottom of the screen with my thumb can be
> awkward.

Thanks for the feedback. Very helpful.

> > > > Just a couple of things: The title bar is too cramped now.  Other apps
> > use
> > > > that to display info on the current context.  We could display "Dive
> > list"
> > > > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> > >
> > > That's a good idea... but I think I like the idea of it simply fading
> > away
> > > even better.
> >
> > +1 for fading away.
> >
> 
> I agree with both points.  Screen real estate is scarce, so if/when the
> title bar is shown, I think it should be more informative than
> Subsurface-mobile (I know what app I'm using).
> 
> Going through the various apps on my phone, many have "title" bars showing
> what page is active on the app (e.g. "Inbox" in gmail), or toolbars, some
> including the app logo (e.g. Twitter), but very few have a title bar with
> the app name displayed.  A few have a search bar that mentions the app name
> (e.g. "Search Google Maps").

I think I'm sold on dropping the name from the title bar. But I'm not 100%
sure what I want instead. No title bar at all? A title bar that fades?
What is it showing until it disappears? Contextual info (which dive is
shown or something like that)?

> In my opinion, the ideal title bar would have the Subsurface-mobile logo at
> left (like now, but moved down a tiny bit - right now its vertical
> alignment is hard against the top of the screen), with the page name next
> to it (e.g. Dive #643 as suggested by Henrik).  And ideally it would fade
> away when you scroll down the page, and probably reappear when you scroll
> back up to the top.

Yeah, so that's kinda what I was contemplating.

> > Google's apps for Android (those which do not auto-save) do use such a
> > dialog.
> > They all use a Discard/Cancel approach (though with completely different
> > wording and even inconsistent button position between the apps, which is
> > really bad design).
> > We haven't written about it in the HIG yet (we'll still add one guideline
> > for
> > that), but here's what I'd suggest:
> > "Discard your changes?" [Discard] [Keep Editing]". This makes saving take
> > one
> > more step, but we want to train users to just hit "Save" anyway, and it
> > makes
> > the decision in the dialog easier.
> > There is already a component for a slide-in dialog available (don't know
> > its
> > name, though, tbh. If you can't find it, ask Marco).
> 
> I find confirmation dialogs clumsy and don't like them if they can be
> avoided, especially on a mobile app.  If we were talking about
> writing/editing a thesis, I'd be more inclined towards a confirmation
> dialog, but if the the user accidentally close the dive edit page without
> saving, and lost their logging notes, they should be able to cope.
> 
> I'd rather have the action button action be 'save changes and close', and
> the Android back button would be 'discard changes and close'.  If that's
> too out the for new users, there could also be a discard button next to the
> current save (and close) ordinary button at the bottom of the page.

So I tried to implement something that I find reasonable and intuitive.

- there's still the save button
- the action button is cancel and there is NO CONFIRMATION - you hit that
  button, you get what you asked for
- the back button asks the user if they really wanted to discard the
  changes, and if they don't confirm within 3 seconds it simply hides the
  confirmation dialog and pretends nothing happens

Please play with it, the description sounds a lot more awkward that it
felt to me to use...

> Similarly, I think we should use the action button on the cloud
> credentials.  The action button action would be "save", and the back button
> would be "discard" (and return to dive list).  This could replace the
> existing ordinary buttons.

That I think is a good idea. I'll need to find the time to implement this.

> Another thing - In the dive list, there's a blank row above the trip
> separator line.  I'm not sure if that's deliberate, but it looks like a
> waste of space to me.

Do you have a screen shot?

Thanks for all the feedback!

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


Re: Subsurface-mobile for Android -845

2016-02-13 Thread Rick Walsh
On 14 February 2016 at 09:54, Thomas Pfeiffer 
wrote:

> On Samstag, 13. Februar 2016 09:57:21 CET Dirk Hohndel wrote:
> > > Hi!  I think it looks pretty decent now.  I like that there is less
> > > clutter.
> > Yay!
>
> Yay++
>
> I just tested 849.  I think the use of the action button is very good.  It
doesn't waste space, it's transparent enough not to be invasive, it's easy
to reach, and most importantly, the icons give good clues what the button
does (unlike the original action button, which was powerful, efficient use
of space, but confusing to many the first time they saw it).  I also like
that I can still/again swipe the central action button instead of using the
arrows - as I said before, when holding my phone in my not-dainty left
hand, reaching the very left bottom of the screen with my thumb can be
awkward.


> > > Just a couple of things: The title bar is too cramped now.  Other apps
> use
> > > that to display info on the current context.  We could display "Dive
> list"
> > > or "Dive #643" or "Edit dive #242" or "About" there in the future.
> >
> > That's a good idea... but I think I like the idea of it simply fading
> away
> > even better.
>
> +1 for fading away.
>

I agree with both points.  Screen real estate is scarce, so if/when the
title bar is shown, I think it should be more informative than
Subsurface-mobile (I know what app I'm using).

Going through the various apps on my phone, many have "title" bars showing
what page is active on the app (e.g. "Inbox" in gmail), or toolbars, some
including the app logo (e.g. Twitter), but very few have a title bar with
the app name displayed.  A few have a search bar that mentions the app name
(e.g. "Search Google Maps").

In my opinion, the ideal title bar would have the Subsurface-mobile logo at
left (like now, but moved down a tiny bit - right now its vertical
alignment is hard against the top of the screen), with the page name next
to it (e.g. Dive #643 as suggested by Henrik).  And ideally it would fade
away when you scroll down the page, and probably reappear when you scroll
back up to the top.


> > > And since we're going for the action button design, how about making it
> > > more like the action buttons in other apps, i.e. larger and more to the
> > > right?
> >
> > Thomas answered the "more to the right" question. But there's another
> > reason. Right now, when you use your device in landscape mode you get the
> > action button right on the center divider which is perfect, IMHO.
> >
> > > And one more (less related) thing:  If I edit a dive and press the back
> > > button (instead of save), I should get a request: "Discard edits? [Yes
> /
> > > Save edits / Cancel]
> >
> > I hate those dialogs on some level, but I guess you are right.
>
> > Thomas, what's the HID approved way of doing something like that?
>
> We originally had the idea that for "swipe to go back/forward" or "column-
> based navigation", one could simply swipe forward again to get back to the
> already entered/changed data if one has accidentally swiped back without
> saving (before navigating somewhere else). That's not as easily possible
> when
> using the back button, of course.
>
> Google's apps for Android (those which do not auto-save) do use such a
> dialog.
> They all use a Discard/Cancel approach (though with completely different
> wording and even inconsistent button position between the apps, which is
> really bad design).
> We haven't written about it in the HIG yet (we'll still add one guideline
> for
> that), but here's what I'd suggest:
> "Discard your changes?" [Discard] [Keep Editing]". This makes saving take
> one
> more step, but we want to train users to just hit "Save" anyway, and it
> makes
> the decision in the dialog easier.
> There is already a component for a slide-in dialog available (don't know
> its
> name, though, tbh. If you can't find it, ask Marco).
>
> I find confirmation dialogs clumsy and don't like them if they can be
avoided, especially on a mobile app.  If we were talking about
writing/editing a thesis, I'd be more inclined towards a confirmation
dialog, but if the the user accidentally close the dive edit page without
saving, and lost their logging notes, they should be able to cope.

I'd rather have the action button action be 'save changes and close', and
the Android back button would be 'discard changes and close'.  If that's
too out the for new users, there could also be a discard button next to the
current save (and close) ordinary button at the bottom of the page.

Similarly, I think we should use the action button on the cloud
credentials.  The action button action would be "save", and the back button
would be "discard" (and return to dive list).  This could replace the
existing ordinary buttons.


Another thing - In the dive list, there's a blank row above the trip
separator line.  I'm not sure if that's deliberate, but it looks like a
waste of space to me.

Cheers,

Rick

Subsurface-mobile for Android -845

2016-02-12 Thread Dirk Hohndel
Hi there.

845 should address the issues that were mentioned

- I think I finally figured out the hang with incorrect credentials
- I FINALLY paid enough attention to realize why the 'Save' after an edit 
accessed the network - that should be fixed now
- the redundant context menus are gone. Android users are comfortable using the 
back button to go up / back a level and to cancel an operation

So I think this is the UI direction I'm leaning towards. Small title bar with 
no menus / buttons. Action button when there's an action. Handle to open global 
menu / drawer (but swipe from the side works as well). Right now we have no 
screen that has a context menu.

There certainly is room for fine-tuning (I just noticed that the icon / text in 
the title bar aren't vertically centered - also the drawer handle maybe isn't 
the final design, yet - this is just my quick hack to give Thomas and Marco an 
idea of what I'm thinking). But unless I hear strong and well reasoned feedback 
from Henrik or some of the others who have been rather outspoken on wanting the 
more Android typical menu / action buttons in the top bar, I think that's where 
we'll go.

I realize that I'm going back and forth on this. Guilty as charged. This is 
hard. But I spent almost an hour with a 4" phone, a 5.7" phone, a 7" tablet and 
a 10" tablet and I think I'm happy with what we have.

Assuming we can get reasonable consensus (or only mostly unconvincing whining), 
I'll do a second beta based on this UI idea (after Marco helps me with the fine 
tuning mentioned above).

Thoughts? Comments?

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-06 Thread Tomaz Canabrava
Got some time and hacking today
Em 6 de fev de 2016 04:58, "Dirk Hohndel"  escreveu:

> On Fri, Feb 05, 2016 at 10:04:26PM -0800, Dirk Hohndel wrote:
> > > Editing weight (from 0.0 kg) wouldn't save.
> >
> > Uh, yeah, that's not hooked up, yet. Oops.
>
> OK, I tried to implement that. It's not super pretty, but I think it works
> as intended. When editing a dive with more than one weightsystem you are
> told that you can't edit the weight. Otherwise the edited weight is parsed
> and updated.
>
> This has received "a tiny bit of testing" :)
>
> And for the third time tonight, new APKs are on their way. These will be
> 4.5.2-780 -- oh my the commit numbers are getting up there already again.
>
> /D
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
> 
> It does have the bug where you need to press edit a dozen times before you
> can edit a dive.

I hate Heisenbugs. So I modified the mobile components to print out debug
information whenever the ActionButton is tapped. And of course with that
in place it always works, reliably, on the first attempt :-(

I have now added this to the next official build just to see if this is
just a fluke here or if this really fixes things for everyone. Same
visible version number (as this is a change to the mobile components).
Please re-download
downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5.arm.apk
and test if the "press edit takes many many attempts" still happens for
you. If it does, I'd love to see the logcat output...

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 February 2016 at 08:48, Dirk Hohndel <d...@hohndel.org> wrote:

> On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
> >
> > It does have the bug where you need to press edit a dozen times before
> you
> > can edit a dive.
>
> I hate Heisenbugs. So I modified the mobile components to print out debug
> information whenever the ActionButton is tapped. And of course with that
> in place it always works, reliably, on the first attempt :-(
>
> I have now added this to the next official build just to see if this is
> just a fluke here or if this really fixes things for everyone. Same
> visible version number (as this is a change to the mobile components).
> Please re-download
> downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5.arm.apk
> and test if the "press edit takes many many attempts" still happens for
> you. If it does, I'd love to see the logcat output...
>

You're easily pleased. On first try it took 15 attempts to press the button

I/Timeline( 8323): Timeline: Activity_launch_request
id:org.subsurfacedivelog.mobile time:889309432
V/ApplicationPolicy( 3534): isApplicationStateBlocked userId 0 pkgname
org.subsurfacedivelog.mobile
V/WindowManager( 3534): addAppToken: AppWindowToken{2417e582
token=Token{208588cd ActivityRecord{17dfce64 u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
t12296}}} to stack=1 task=12296 at 0
V/ApplicationPolicy( 3534): isApplicationStateBlocked userId 0 pkgname
org.subsurfacedivelog.mobile
I/ActivityManager( 3534): Start proc
9:org.subsurfacedivelog.mobile/u0a1024 for activity
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
V/WindowManager( 3534): Adding window Window{3d059894 u0 d0 Starting
org.subsurfacedivelog.mobile} at 8 of 15 (after Window{38483b09 u0 d0
com.sec.android.app.launcher/com.sec.android.app.launcher.activities.LauncherActivity})
D/ActivityManager( 3534):  Launching org.subsurfacedivelog.mobile, updated
priority
D/StatusBarManagerService( 3534): manageDisableList userId=0 what=0x0
pkg=Window{3d059894 u0 d0 Starting org.subsurfacedivelog.mobile}
V/ActivityManager( 3534): getServiceTotalTransactions  package =
org.subsurfacedivelog.mobile and package's services is null !!!
V/ActivityManager_SPCMtest( 3534): Launched -: org.subsurfacedivelog.mobile
D/InjectionManager(9): fillFeatureStoreMap org.subsurfacedivelog.mobile
I/InjectionManager(9): Constructor org.subsurfacedivelog.mobile,
Feature store :{}
V/WindowManager( 3534): Adding window Window{c7aa5d7 u0 d0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity}
at 8 of 16 (before Window{3d059894 u0 d0 Starting
org.subsurfacedivelog.mobile})
D/StatusBarManagerService( 3534): manageDisableList userId=0 what=0x0
pkg=Window{c7aa5d7 u0 d0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity}
W/Subsurface(9): (null):0 ((null)): QFont::setPointSizeF: Point size <=
0 (-1.00), must be greater than 0
I/Timeline( 3534): Timeline: Activity_windows_visible id:
ActivityRecord{17dfce64 u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
t12296} time:889311556
D/Subsurface(9): /data/android/subsurface/qt-mobile/qmlmanager.cpp:51
(QMLManager::QMLManager()): Starting "Subsurface-mobile:4.5.2.774:Android
5.1.1:arm:en-AU"
D/Subsurface(9): /data/android/subsurface/qt-mobile/qmlmanager.cpp:52
(QMLManager::QMLManager()): "build with Qt Version 5.5.0, runtime from Qt
Version 5.5.0"
D/Subsurface(9):
/data/android/subsurface/subsurface-core/gpslocation.cpp:154 (void
GpsLocation::status(QString)): "created GPS source"
D/Subsurface(9):
/data/android/subsurface/subsurface-core/gpslocation.cpp:154 (void
GpsLocation::status(QString)): "Found GPS"
V/WindowManager( 3534): Adding window Window{d8a7ba9 u0 d0 SurfaceView} at
8 of 16 (before Window{c7aa5d7 u0 d0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity})
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subsurface(9): (null):0 ((null)): This plugin does not support
setting window opacity
W/Subs

Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 10:04:26PM -0800, Dirk Hohndel wrote:
> > Editing weight (from 0.0 kg) wouldn't save.
> 
> Uh, yeah, that's not hooked up, yet. Oops.

OK, I tried to implement that. It's not super pretty, but I think it works
as intended. When editing a dive with more than one weightsystem you are
told that you can't edit the weight. Otherwise the edited weight is parsed
and updated.

This has received "a tiny bit of testing" :)

And for the third time tonight, new APKs are on their way. These will be
4.5.2-780 -- oh my the commit numbers are getting up there already again.

/D

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


punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
Hi there,

the last couple of weeks have been challenging for me to find time to work
on Subsurface and that's frustrating because I think we are really close
to being able to open this up for more users.

I figured we should create a punch list of what's missing to get us there.
I'll convert this into bugs on trac bug for now let's just collect things
here:

- edit button: the magic button has suddenly become super unreliable. I
  have to tap it many many times before it starts the edit. And obviously
  several others have reported this already as well.
  Marco, Sebastian, any idea what's up with that?
  As a stop gap measure I think we should add back a button in the TopBar
  that switches from "Edit" to "Cancel".

- keyboard size error: especially in landscape - the content of the page
  being edited shifts up too much and there's a big empty area above the
  keyboard.
  Sebastian, I know that you said you know what causes that. Any chance
  you can look into this issue?

- disable download from dive computer menu entry: since this isn't hooked
  up, we shouldn't expose it to the user.

- enable DC provided ceiling in red: that's like a two liner patch to just
  enable those options in the settings

- fix the blue line on top of the profile:
  Tomaz, you said you fixed this - but haven't sent patches

What else is there that needs to get done / fixed / disabled before we can
release this for the first time as public beta?

Thanks

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 05:01:16PM +0100, Marco Martin wrote:
> > 
> > - edit button: the magic button has suddenly become super unreliable. I
> >   have to tap it many many times before it starts the edit. And obviously
> >   several others have reported this already as well.
> >   Marco, Sebastian, any idea what's up with that?
> >   As a stop gap measure I think we should add back a button in the TopBar
> >   that switches from "Edit" to "Cancel".
> 
> is it now using the components from master?

Yes - my build script automatically pulls the latest from the plasma
mobile master prior to creating an APK.

> > - keyboard size error: especially in landscape - the content of the page
> >   being edited shifts up too much and there's a big empty area above the
> >   keyboard.
> >   Sebastian, I know that you said you know what causes that. Any chance
> >   you can look into this issue?
> 
> maybe for the first release the attached patch should be used until we figure 
> out what't broken in keyboard management in Android

> diff --git a/components/mobilecomponents/qml/ApplicationWindow.qml 
> b/components/mobilecomponents/qml/ApplicationWindow.qml
> index c71c4e9..8b6342e 100644
> --- a/components/mobilecomponents/qml/ApplicationWindow.qml
> +++ b/components/mobilecomponents/qml/ApplicationWindow.qml
> @@ -131,7 +131,6 @@ ApplicationWindow {
>  id: __pageStack
>  anchors {
>  fill: parent
> -bottomMargin: Qt.inputMethod.keyboardRectangle.height
>  }
>  focus: true
>  Keys.onReleased: {

Sure, I can do that and test if that fixes the problem. Unfortunately I
didn't bring my 10" tablet (where this is the easiest to reproduce) to the
office this morning.

/D

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 06:04:06PM +0200, Willem Ferguson wrote:
> 1) It is not only the magic button that needs numerous taps. Also all the
> options on the lefthand slide-out panel.

interesting. that I have not run into, yet.

> 2) Subsurface-mobile crashes on some versions of Android 5.1 (e.g. most
> recent build 766). I suspect the fix is simple.

No it isn't. This is the weird annoying problem that seems to be limited
to some Samsung devices and is related to the grid layout with the dive
number on the same line as the date, right? We still have no idea what
causes this. Not doing it causes clipping issues on some other devices.

So no simple fix that I'm aware of.

> 3) If one can hand-add a manual dive entry to the dive log, one must also be
> able to hand-delete a dive from the dive log,
> otherwise there is no way to get rid of a hand-entered dive with
> unexpected or undesirable information.

"must" is a strong word. I'd go with "should". Yes, I agree in principle,
but this isn't something I'd hold the open beta for.

> I will throw together some type of documentation as a user guide for
> Subsurface-mobile. Using ASCIIDOC? Separate doc from user manual of desktop
> version, I suspect?

Yes please. On both questions.

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Sebastian Kügler
On Friday, February 05, 2016 07:47:52 Dirk Hohndel wrote:
> the last couple of weeks have been challenging for me to find time to work
> on Subsurface and that's frustrating because I think we are really close
> to being able to open this up for more users.

Exactly the same feeling and constraints here. High five, bro.

The punchlist is very useful, it also show how close we really are. Thanks for 
compiling it.

> I figured we should create a punch list of what's missing to get us there.
> I'll convert this into bugs on trac bug for now let's just collect things
> here:
> 
> - edit button: the magic button has suddenly become super unreliable. I
>   have to tap it many many times before it starts the edit. And obviously
>   several others have reported this already as well.
>   Marco, Sebastian, any idea what's up with that?
>   As a stop gap measure I think we should add back a button in the TopBar
>   that switches from "Edit" to "Cancel".

Would be good if Marco can have a look, he knows this code. I hope it's not 
some weird Android-related input bug, but since it worked reliably before, we 
may be lucky.

> - keyboard size error: especially in landscape - the content of the page
>   being edited shifts up too much and there's a big empty area above the
>   keyboard.
>   Sebastian, I know that you said you know what causes that. Any chance
>   you can look into this issue?

I'll prioritize this, you'll hear from me shortly.

Cheers,
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 08:35:48PM +0200, Willem Ferguson wrote:
> On 05/02/2016 19:08, Dirk Hohndel wrote:
> >On Fri, Feb 05, 2016 at 06:04:06PM +0200, Willem Ferguson wrote:
> >>1) It is not only the magic button that needs numerous taps. Also all the
> >>options on the lefthand slide-out panel.
> >interesting. that I have not run into, yet.
> 
> Only in Android 5.1. Android 4.3 ok.

I think it's a lot more than just the Android version that matters. It
also matters which UI layer is run on top of it. Samsung, HTC, Sony, they
all have their own crap on top of Android and some of the bugs only seem
to happen with a specific version of that.

> >>2) Subsurface-mobile crashes on some versions of Android 5.1 (e.g. most
> >>recent build 766). I suspect the fix is simple.
> >"must" is a strong word. I'd go with "should". Yes, I agree in principle,
> >but this isn't something I'd hold the open beta for.
> Would it be useful to use exactly the mechanism that is used to delete
> GPS fixes from the list of GPS fixes?

I don't think that's needed because we already have a detail view. The
reason I did this in the list for the GPS fixes was that there is no way
to "open" a single GPS fix.

> >>I will throw together some type of documentation as a user guide for
> >>Subsurface-mobile. Using ASCIIDOC? Separate doc from user manual of desktop
> >>version, I suspect?
> Will get down to that.

Thanks

> Oh, and an additional problem. The line editing within a text box is faulty
> both on my Android 4.3 and
> Android 5.1 test machines. Its easy to reproduce. In a new installation,
> where the email address
> for credentials is entered, make a deliberate spelling error. Having typed
> in the complete email
> address, then do a long press to bring up the cursor to the spelling error.
> Try to drag the cursor
> using the blue tag and position it immediately after the spelling error. Try
> to correct. The string is
> scrambled. I have found this in one or 2 of the edit fields in dive edit as
> well. Both Android 4.3 and 5.1.

And again I wonder if this is vendor specific. I don't see this with my
Android 4.3 Nexus device.

> I have not looked at the code, but is there an easy way for me to switch on
> the download to divecomputer
> option for test purposes?

Yes - it's just commented out code in main.qml. 

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 06:33:18PM +0100, Marco Martin wrote:
> On Friday 05 February 2016 09:17:23 you wrote:
> > I can find that code but what concerns me... in my copy (from master, see
> > above), that's line 63, not line 134 as in your diff. Am I pulling from
> > the wrong repo? I have git://github.com/KDE/plasma-mobile and a quick
> > check online at
> > https://github.com/KDE/plasma-mobile/blob/master/components/mobilecomponents
> > /qml/ApplicationWindow.qml confirms what I see... this is line 63.
> > 
> > So... did you forget to push something that should be upstream but isn't?
> 
> ah, right sorry, this was against a branch.

No problem.

> What i'm going to do for now is to selectively disable such bottom margin on 
> android since qml exposes the platform name, so you can keep using just 
> master 

Will do. The latest apk (-773) was built with your patch and on my 6"
phone I can't seem to reproduce the bug (but it didn't happen there all
that often - I could quite reliably reproduce it on my 10" tablet that I
didn't bring to the office today).

The "action button is unresponsive and takes many taps to activate" issue
is easily reproduced with that latest binary, though...

Any idea what might be causing that? This used to work very reliably :-(

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread David Tillotson
On 5 February 2016 17:48:04 GMT+00:00, Dirk Hohndel  wrote:
>Will do. The latest apk (-773) was built with your patch and on my 6"
>phone I can't seem to reproduce the bug (but it didn't happen there all
>that often - I could quite reliably reproduce it on my 10" tablet that
>I
>didn't bring to the office today).
>
>The "action button is unresponsive and takes many taps to activate"
>issue
>is easily reproduced with that latest binary, though...
>
>Any idea what might be causing that? This used to work very reliably
>:-(
>
>/D
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

The edit box now works without the huge white panel :)
On hitting the Save button, it drops out of edit mode, but the keyboard stays 
on screen until hitting the back button. Is there a missing dismissal of the 
keyboard?
Other than the edit button response and the superfluous (for now) menu entries, 
this is pretty much complete as far as I can tell.
-- 
David Tillotson
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Willem Ferguson

On 05/02/2016 19:08, Dirk Hohndel wrote:

On Fri, Feb 05, 2016 at 06:04:06PM +0200, Willem Ferguson wrote:

1) It is not only the magic button that needs numerous taps. Also all the
options on the lefthand slide-out panel.

interesting. that I have not run into, yet.


Only in Android 5.1. Android 4.3 ok.

2) Subsurface-mobile crashes on some versions of Android 5.1 (e.g. most
recent build 766). I suspect the fix is simple.

"must" is a strong word. I'd go with "should". Yes, I agree in principle,
but this isn't something I'd hold the open beta for.

Would it be useful to use exactly the mechanism that is used to delete
GPS fixes from the list of GPS fixes?

I will throw together some type of documentation as a user guide for
Subsurface-mobile. Using ASCIIDOC? Separate doc from user manual of desktop
version, I suspect?

Will get down to that.

Oh, and an additional problem. The line editing within a text box is 
faulty both on my Android 4.3 and
Android 5.1 test machines. Its easy to reproduce. In a new installation, 
where the email address
for credentials is entered, make a deliberate spelling error. Having 
typed in the complete email
address, then do a long press to bring up the cursor to the spelling 
error. Try to drag the cursor
using the blue tag and position it immediately after the spelling error. 
Try to correct. The string is
scrambled. I have found this in one or 2 of the edit fields in dive edit 
as well. Both Android 4.3 and 5.1.


I have not looked at the code, but is there an easy way for me to switch 
on the download to divecomputer

option for test purposes?

Kind regards,
willem

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 05:01:16PM +0100, Marco Martin wrote:
> 
> is it now using the components from master?

Latest I have is
commit 42c55621a4b99916220d68052f85df6735b7c20b
Author: Dan Leinir Turthra Jensen 
Date:   Wed Feb 3 12:32:11 2016 +

Make the (physical) back button work again for the application window's 
pagestack


> maybe for the first release the attached patch should be used until we figure 
> out what't broken in keyboard management in Android
> 
> -- 
> Marco Martin

> diff --git a/components/mobilecomponents/qml/ApplicationWindow.qml 
> b/components/mobilecomponents/qml/ApplicationWindow.qml
> index c71c4e9..8b6342e 100644
> --- a/components/mobilecomponents/qml/ApplicationWindow.qml
> +++ b/components/mobilecomponents/qml/ApplicationWindow.qml
> @@ -131,7 +131,6 @@ ApplicationWindow {
>  id: __pageStack
>  anchors {
>  fill: parent
> -bottomMargin: Qt.inputMethod.keyboardRectangle.height
>  }
>  focus: true
>  Keys.onReleased: {


I can find that code but what concerns me... in my copy (from master, see
above), that's line 63, not line 134 as in your diff. Am I pulling from
the wrong repo? I have git://github.com/KDE/plasma-mobile and a quick
check online at
https://github.com/KDE/plasma-mobile/blob/master/components/mobilecomponents/qml/ApplicationWindow.qml
confirms what I see... this is line 63.

So... did you forget to push something that should be upstream but isn't?


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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 06:29:17PM +, David Tillotson wrote:
> 
> The edit box now works without the huge white panel :)

Cool - thanks for reporting that.

> On hitting the Save button, it drops out of edit mode, but the keyboard stays 
> on screen until hitting the back button. Is there a missing dismissal of the 
> keyboard?

Hmm. I can't hit save without closing the keyboard first... so how did you
manage to do that? And yes, of course, that should close the keyboard as
well.

> Other than the edit button response and the superfluous (for now) menu 
> entries, this is pretty much complete as far as I can tell.

Which menu entries are superfluous? Can you file a bug so we can track
that?

Thanks

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread David Tillotson
On 5 February 2016 18:53:36 GMT+00:00, Dirk Hohndel  wrote:
>On Fri, Feb 05, 2016 at 10:32:07AMr -0800, Dirk Hohndel wrote:
>> 
>> > On hitting the Save button, it drops out of edit mode, but the
>keyboard stays on screen until hitting the back button. Is there a
>missing dismissal of the keyboard?
>> 
>> Hmm. I can't hit save without closing the keyboard first... so how
>did you
>> manage to do that? And yes, of course, that should close the keyboard
>as
>> well.
>
>Can you try the latest build (-774) which tries to make sure the
>keyboard
>is always closed when we leave edit mode
>
>/D

This works as expected. I tend to use Samsung's floating mini keyboard, as the 
screen is big enough.
I mentioned the menu entries referring to the DC download (and possibly 
Developer) entry, as I hadn't noticed the DC entry is already gone!
On a bit more thorough testing, I did find that the edit mode stays active on 
backing up from a dive, until either hitting Save, Cancel, or going into a menu 
panel that has entry fields. Not a showstopper, but odd behaviour from a user 
point of view.
-- 
David Tillotson
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 08:57:49AM +1100, Rick Walsh wrote:
> On 6 February 2016 at 08:48, Dirk Hohndel  wrote:
> 
> > On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
> > >
> > > It does have the bug where you need to press edit a dozen times before
> > you
> > > can edit a dive.
> >
> > I hate Heisenbugs. So I modified the mobile components to print out debug
> > information whenever the ActionButton is tapped. And of course with that
> > in place it always works, reliably, on the first attempt :-(
> >
> > I have now added this to the next official build just to see if this is
> > just a fluke here or if this really fixes things for everyone. Same
> > visible version number (as this is a change to the mobile components).
> > Please re-download
> > downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5.arm.apk
> > and test if the "press edit takes many many attempts" still happens for
> > you. If it does, I'd love to see the logcat output...
> >
> 
> You're easily pleased. On first try it took 15 attempts to press the button

Now I'm confused again. What else is new. Next attempt. Can you download
the latest one and try (stupidly still with the same filename - sorry)

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 February 2016 at 09:10, Dirk Hohndel  wrote:

> On Sat, Feb 06, 2016 at 08:57:49AM +1100, Rick Walsh wrote:
> > On 6 February 2016 at 08:48, Dirk Hohndel  wrote:
> >
> > > On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
> > > >
> > > > It does have the bug where you need to press edit a dozen times
> before
> > > you
> > > > can edit a dive.
> > >
> > > I hate Heisenbugs. So I modified the mobile components to print out
> debug
> > > information whenever the ActionButton is tapped. And of course with
> that
> > > in place it always works, reliably, on the first attempt :-(
> > >
> > > I have now added this to the next official build just to see if this is
> > > just a fluke here or if this really fixes things for everyone. Same
> > > visible version number (as this is a change to the mobile components).
> > > Please re-download
> > > downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5.arm.apk
> > > and test if the "press edit takes many many attempts" still happens for
> > > you. If it does, I'd love to see the logcat output...
> > >
> >
> > You're easily pleased. On first try it took 15 attempts to press the
> button
>
> Now I'm confused again. What else is new. Next attempt. Can you download
> the latest one and try (stupidly still with the same filename - sorry)
>
>
Worked first time, and several times in a row after that.

D/Subsurface(16684):
qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:87
(onClicked): qml: ActionButton clicked QQuickAction(0xdb34f0a0)function() {
[code] }
D/Subsurface(16684):
qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:99
(onClicked): qml: triggering action
W/Subsurface(16684): (null):0 ((null)): Could not resolve property :
linearGradient4538
W/Subsurface(16684): (null):0 ((null)): Could not resolve property :
linearGradient4588

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
That's what I guessed before having to run. Please submit upstream

/D



-- 
Sent from my phone

> On Feb 5, 2016, at 14:39, Rick Walsh  wrote:
> 
> 
> 
>> On 6 February 2016 at 09:15, Rick Walsh  wrote:
>> 
>> 
>>> On 6 February 2016 at 09:10, Dirk Hohndel  wrote:
>>> On Sat, Feb 06, 2016 at 08:57:49AM +1100, Rick Walsh wrote:
>>> > On 6 February 2016 at 08:48, Dirk Hohndel  wrote:
>>> >
>>> > > On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
>>> > > >
>>> > > > It does have the bug where you need to press edit a dozen times before
>>> > > you
>>> > > > can edit a dive.
>>> > >
>>> > > I hate Heisenbugs. So I modified the mobile components to print out 
>>> > > debug
>>> > > information whenever the ActionButton is tapped. And of course with that
>>> > > in place it always works, reliably, on the first attempt :-(
>>> > >
>>> > > I have now added this to the next official build just to see if this is
>>> > > just a fluke here or if this really fixes things for everyone. Same
>>> > > visible version number (as this is a change to the mobile components).
>>> > > Please re-download
>>> > > downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5.arm.apk
>>> > > and test if the "press edit takes many many attempts" still happens for
>>> > > you. If it does, I'd love to see the logcat output...
>>> > >
>>> >
>>> > You're easily pleased. On first try it took 15 attempts to press the 
>>> > button
>>> 
>>> Now I'm confused again. What else is new. Next attempt. Can you download
>>> the latest one and try (stupidly still with the same filename - sorry)
>> 
>> Worked first time, and several times in a row after that.
>> 
>> D/Subsurface(16684): 
>> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:87 
>> (onClicked): qml: ActionButton clicked QQuickAction(0xdb34f0a0)function() { 
>> [code] }
>> D/Subsurface(16684): 
>> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:99 
>> (onClicked): qml: triggering action
>> W/Subsurface(16684): (null):0 ((null)): Could not resolve property : 
>> linearGradient4538
>> W/Subsurface(16684): (null):0 ((null)): Could not resolve property : 
>> linearGradient4588
>>  
>> Rick
> 
> 
> I'm not sure if you've already worked out what I just did, but I added a 
> little debug output myself to find out where the (mouse.x < buttonGraphics.x 
> || mouse.x > buttonGraphics.x + buttonGraphics.width) condition was going 
> wrong.
> 
> D/Subsurface(24634): 
> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:88 
> (onClicked): qml: outside zone - mouse.x:  719 ; buttonGraphics.x:  738 ; 
> buttonGraphics.width:  114
> D/Subsurface(24634): 
> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:88 
> (onClicked): qml: outside zone - mouse.x:  680 ; buttonGraphics.x:  738 ; 
> buttonGraphics.width:  114
> D/Subsurface(24634): 
> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:88 
> (onClicked): qml: outside zone - mouse.x:  721 ; buttonGraphics.x:  738 ; 
> buttonGraphics.width:  114
> D/Subsurface(24634): 
> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:88 
> (onClicked): qml: outside zone - mouse.x:  693 ; buttonGraphics.x:  738 ; 
> buttonGraphics.width:  114
> D/Subsurface(24634): 
> qrc:imports/org/kde/plasma/mobilecomponents/private/ActionButton.qml:91 
> (onClicked): qml: within zone - mouse.x:  757 ; buttonGraphics.x:  738 ; 
> buttonGraphics.width:  114
>  
> It appears that the button is centre aligned, so buttonGraphics.x relates to 
> the middle of the button. Click just to the left of the centre and it fails, 
> click just to the right and it works.
> 
> I've fixed the problem with this little change:
> 
> $ diff ../subsurface/qt-mobile/qml/mobilecomponents/private/ActionButton.qml 
> components/mobilecomponents/qml/private/ActionButton.qml 
> 87c87
> < if (mouse.x < buttonGraphics.x - buttonGraphics.width / 2 || 
> mouse.x > buttonGraphics.x + buttonGraphics.width / 2) {
> ---
> > if (mouse.x < buttonGraphics.x || mouse.x > buttonGraphics.x + 
> > buttonGraphics.width) {
> 
> 
> Did you come to the same conclusion? I'm guessing you've already worked out a 
> solution, but if not and you think that's correct, I'll submit that upstream.
> 
> Rick
> 
> 
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 February 2016 at 06:46, Dirk Hohndel  wrote:

> On Sat, Feb 06, 2016 at 06:27:00AM +1100, Rick Walsh wrote:
> > >
> > > So no simple fix that I'm aware of.
> > >
> > My build of 766 doesn't crash on my Samsung, but yours does (as does
> 774).
> > I thought the difference was Qt5.5 vs Qt5.6, but I just realized what
> might
> > be a more substantial difference in our builds.
> >
> > I tend to run the build script only periodically. Most of the time,
> > especially when working on a patch, I'll just run make inside the build
> > dir. So, my version will be a few commits behind in the Plasma
> > mobilecomponents. I suspect the crashes I get reliably might be linked
> to a
> > recent commit mobilecomponents change. I'll do some testing and report
> back.
> >
> > Here's to hoping it's an easy fix.
>
> Always :-)
>

I was one mobilecomponents commit behind, 42c5562 'Make the (physical) back
button work again for the application window's pagestack'.  I updated and
rebuilt the apk, but that version didn't crash for me.

Note, there's another, minutes-old commit to mobilecomponents, 535e26f
'don't make space for keyboard on Android'. It didn't cause or prevent a
crash for me, but maybe it fixes keyboard issues for others?

In summary, it doesn't look like the mobilecomponents changes are related
to my crashes.


> I can easily create a Qt5.5.1 based build for cross testing. Let me know.
>
> Please do. It sounds much easier than me building Qt5.6 master. I'm
interested to compare the latest subsurface-mobile built with both versions
on the same machine.

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 12:25:19PM -0800, Dirk Hohndel wrote:
> 
> > > I can easily create a Qt5.5.1 based build for cross testing. Let me know.
> > >
> > > Please do. It sounds much easier than me building Qt5.6 master. I'm
> > interested to compare the latest subsurface-mobile built with both versions
> > on the same machine.
> 
> OK, new build coming up.

Give it a try:

http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5-release-arm.apk

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 07:40:35AM +1100, Rick Walsh wrote:
> On 6 February 2016 at 07:34, Dirk Hohndel  wrote:
> 
> > On Fri, Feb 05, 2016 at 12:31:27PM -0800, Dirk Hohndel wrote:
> > > On Fri, Feb 05, 2016 at 12:25:19PM -0800, Dirk Hohndel wrote:
> > > >
> > > > > > I can easily create a Qt5.5.1 based build for cross testing. Let
> > me know.
> > > > > >
> > > > > > Please do. It sounds much easier than me building Qt5.6 master. I'm
> > > > > interested to compare the latest subsurface-mobile built with both
> > versions
> > > > > on the same machine.
> > > >
> > > > OK, new build coming up.
> > >
> > > Give it a try:
> > >
> > >
> > http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5-release-arm.apk
> >
> > Err, oops, that one is 5.5.0 based it seems. Still, give it a try, please.
> 
> I tried and it doesn't crash.

So... 5.6 causes the crash. Lovely :-(

> It does have the bug where you need to press edit a dozen times before you
> can edit a dive.

I'm trying to figure out how to instrument things to understand what's
going on there...

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 Feb 2016 04:09, "Dirk Hohndel"  wrote:
>
> On Fri, Feb 05, 2016 at 06:04:06PM +0200, Willem Ferguson wrote:
> > 2) Subsurface-mobile crashes on some versions of Android 5.1 (e.g. most
> > recent build 766). I suspect the fix is simple.
>
> No it isn't. This is the weird annoying problem that seems to be limited
> to some Samsung devices and is related to the grid layout with the dive
> number on the same line as the date, right? We still have no idea what
> causes this. Not doing it causes clipping issues on some other devices.
>
> So no simple fix that I'm aware of.
>
My build of 766 doesn't crash on my Samsung, but yours does (as does 774).
I thought the difference was Qt5.5 vs Qt5.6, but I just realized what might
be a more substantial difference in our builds.

I tend to run the build script only periodically. Most of the time,
especially when working on a patch, I'll just run make inside the build
dir. So, my version will be a few commits behind in the Plasma
mobilecomponents. I suspect the crashes I get reliably might be linked to a
recent commit mobilecomponents change. I'll do some testing and report back.

Here's to hoping it's an easy fix.

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 07:15:38AM +1100, Rick Walsh wrote:
> On 6 February 2016 at 06:46, Dirk Hohndel  wrote:
> 
> > On Sat, Feb 06, 2016 at 06:27:00AM +1100, Rick Walsh wrote:
> > > >
> > > > So no simple fix that I'm aware of.
> > > >
> > > My build of 766 doesn't crash on my Samsung, but yours does (as does
> > 774).
> > > I thought the difference was Qt5.5 vs Qt5.6, but I just realized what
> > might
> > > be a more substantial difference in our builds.
> > >
> > > I tend to run the build script only periodically. Most of the time,
> > > especially when working on a patch, I'll just run make inside the build
> > > dir. So, my version will be a few commits behind in the Plasma
> > > mobilecomponents. I suspect the crashes I get reliably might be linked
> > to a
> > > recent commit mobilecomponents change. I'll do some testing and report
> > back.
> > >
> > > Here's to hoping it's an easy fix.
> >
> > Always :-)
> >
> 
> I was one mobilecomponents commit behind, 42c5562 'Make the (physical) back
> button work again for the application window's pagestack'.  I updated and
> rebuilt the apk, but that version didn't crash for me.
> 
> Note, there's another, minutes-old commit to mobilecomponents, 535e26f
> 'don't make space for keyboard on Android'. It didn't cause or prevent a
> crash for me, but maybe it fixes keyboard issues for others?
> 
> In summary, it doesn't look like the mobilecomponents changes are related
> to my crashes.

That was my assumption :-/

> > I can easily create a Qt5.5.1 based build for cross testing. Let me know.
> >
> > Please do. It sounds much easier than me building Qt5.6 master. I'm
> interested to compare the latest subsurface-mobile built with both versions
> on the same machine.

OK, new build coming up.

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 06:27:00AM +1100, Rick Walsh wrote:
> >
> > So no simple fix that I'm aware of.
> >
> My build of 766 doesn't crash on my Samsung, but yours does (as does 774).
> I thought the difference was Qt5.5 vs Qt5.6, but I just realized what might
> be a more substantial difference in our builds.
> 
> I tend to run the build script only periodically. Most of the time,
> especially when working on a patch, I'll just run make inside the build
> dir. So, my version will be a few commits behind in the Plasma
> mobilecomponents. I suspect the crashes I get reliably might be linked to a
> recent commit mobilecomponents change. I'll do some testing and report back.
> 
> Here's to hoping it's an easy fix.

Always :-)

I can easily create a Qt5.5.1 based build for cross testing. Let me know.

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 February 2016 at 07:34, Dirk Hohndel  wrote:

> On Fri, Feb 05, 2016 at 12:31:27PM -0800, Dirk Hohndel wrote:
> > On Fri, Feb 05, 2016 at 12:25:19PM -0800, Dirk Hohndel wrote:
> > >
> > > > > I can easily create a Qt5.5.1 based build for cross testing. Let
> me know.
> > > > >
> > > > > Please do. It sounds much easier than me building Qt5.6 master. I'm
> > > > interested to compare the latest subsurface-mobile built with both
> versions
> > > > on the same machine.
> > >
> > > OK, new build coming up.
> >
> > Give it a try:
> >
> >
> http://subsurface-divelog.org/downloads/daily/Subsurface-mobile-4.5.2.774-Qt5.5-release-arm.apk
>
> Err, oops, that one is 5.5.0 based it seems. Still, give it a try, please.
>

I tried and it doesn't crash.

It does have the bug where you need to press edit a dozen times before you
can edit a dive.

Cheers,

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Rick Walsh
On 6 February 2016 at 16:08, Dirk Hohndel <d...@hohndel.org> wrote:

> On Fri, Feb 05, 2016 at 07:47:52AM -0800, Dirk Hohndel wrote:
> > Hi there,
> >
> > the last couple of weeks have been challenging for me to find time to
> work
> > on Subsurface and that's frustrating because I think we are really close
> > to being able to open this up for more users.
> >
> > I figured we should create a punch list of what's missing to get us
> there.
> > I'll convert this into bugs on trac bug for now let's just collect things
> > here:
> >
> > - edit button: the magic button has suddenly become super unreliable. I
> >   have to tap it many many times before it starts the edit. And obviously
> >   several others have reported this already as well.
> >   Marco, Sebastian, any idea what's up with that?
> >   As a stop gap measure I think we should add back a button in the TopBar
> >   that switches from "Edit" to "Cancel".
>
> This should be fixed in 775
>
> > - keyboard size error: especially in landscape - the content of the page
> >   being edited shifts up too much and there's a big empty area above the
> >   keyboard.
> >   Sebastian, I know that you said you know what causes that. Any chance
> >   you can look into this issue?
>
> Also fixed in 775
>
> > - disable download from dive computer menu entry: since this isn't hooked
> >   up, we shouldn't expose it to the user.
>
> Ditto
>
> > - enable DC provided ceiling in red: that's like a two liner patch to
> just
> >   enable those options in the settings
>
> Waiting for a patch from Jan
>
> > - fix the blue line on top of the profile:
> >   Tomaz, you said you fixed this - but haven't sent patches
>
> Waiting for a patch from Tomaz
>
> > What else is there that needs to get done / fixed / disabled before we
> can
> > release this for the first time as public beta?
>
> I'd love a solid round of testing to make sure there are no other little
> bugs. Even if you already reported things (I have this feeling that there
> was another thing somewhere in this thread where a sequence of steps left
> us in edit mode even though we shouldn't be... can't find it right now),
> please test again and report again so we can close them one by one and
> hopefully open up Subsurface-mobile on Android for broader testing.
>
> Thanks and have a good weekend!
>
> <http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface>
>

It's looking good.  The gaschange icons have been far too big on my phone;
I sent a patch to shrink them for subsurface-mobile.

Other than that:
Editing weight (from 0.0 kg) wouldn't save.
Occasionally I get a blank profile after editing fields
I can't crash it

I have a wreck to dive in the morning, so will probably not go near my
computer again for the rest of the weekend.

Have a good weekend too

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Sat, Feb 06, 2016 at 05:01:08PM +1100, Rick Walsh wrote:
> 
> It's looking good.  The gaschange icons have been far too big on my phone;
> I sent a patch to shrink them for subsurface-mobile.

I just pushed that and will create new APKs.

> Other than that:
> Editing weight (from 0.0 kg) wouldn't save.

Uh, yeah, that's not hooked up, yet. Oops.

> Occasionally I get a blank profile after editing fields

I have seen that in the past and am never able to figure out why it
happens. My theory used to be that it was timing issues where the profile
didn't finish drawing by the time it got rendered into the pixmap

> I can't crash it

Good!

> I have a wreck to dive in the morning, so will probably not go near my
> computer again for the rest of the weekend.

Have fun

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


Re: punch list for public beta of Subsurface-mobile for Android

2016-02-05 Thread Dirk Hohndel
On Fri, Feb 05, 2016 at 07:47:52AM -0800, Dirk Hohndel wrote:
> Hi there,
> 
> the last couple of weeks have been challenging for me to find time to work
> on Subsurface and that's frustrating because I think we are really close
> to being able to open this up for more users.
> 
> I figured we should create a punch list of what's missing to get us there.
> I'll convert this into bugs on trac bug for now let's just collect things
> here:
> 
> - edit button: the magic button has suddenly become super unreliable. I
>   have to tap it many many times before it starts the edit. And obviously
>   several others have reported this already as well.
>   Marco, Sebastian, any idea what's up with that?
>   As a stop gap measure I think we should add back a button in the TopBar
>   that switches from "Edit" to "Cancel".

This should be fixed in 775

> - keyboard size error: especially in landscape - the content of the page
>   being edited shifts up too much and there's a big empty area above the
>   keyboard.
>   Sebastian, I know that you said you know what causes that. Any chance
>   you can look into this issue?

Also fixed in 775

> - disable download from dive computer menu entry: since this isn't hooked
>   up, we shouldn't expose it to the user.

Ditto

> - enable DC provided ceiling in red: that's like a two liner patch to just
>   enable those options in the settings

Waiting for a patch from Jan

> - fix the blue line on top of the profile:
>   Tomaz, you said you fixed this - but haven't sent patches

Waiting for a patch from Tomaz

> What else is there that needs to get done / fixed / disabled before we can
> release this for the first time as public beta?

I'd love a solid round of testing to make sure there are no other little
bugs. Even if you already reported things (I have this feeling that there
was another thing somewhere in this thread where a sequence of steps left
us in edit mode even though we shouldn't be... can't find it right now),
please test again and report again so we can close them one by one and
hopefully open up Subsurface-mobile on Android for broader testing.

Thanks and have a good weekend!

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


Profile for Subsurface-mobile on Android

2015-12-01 Thread Dirk Hohndel

So a little digging and a sprinkling of qDebug() statements finally helped me 
to figure out what's going wrong with the profile on Android. It a race 
condition. In a weird backwards way.

So when we call plotDive that updates the dataModel with the plotInfo and then 
emits dataChanged() - the different components of the profile listen to that 
signal and update the graphical representation. The next time the profile is 
painted it all looks as intended.

Now in Subsurface-mobile we called plotDive() and then a couple of lines after 
that we called render to pain the profile into a pixmap. For reasons I'm not 
sure I fully understand, running this under Linux on my laptop always worked. 
But on Android, the paint() members of the different components of the profile 
were called BEFORE the slots that were connected with the dataChanged() signal. 
Which meant that quite frequently very little of the profile was rendered 
correctly.

I believe I have this fixed. I now call plotDive() from QMLProfile::setDiveId() 
and not from QMLProfile::paint() - but if I'm honest I think this is just 
hiding the problem... we need a way to know when the profile is fully updated 
and ready to be rendered...

The other issue that's still confounding me is the sizing of the profile. I 
played around with this and what I'm seeing on screen makes very little sense 
to me. Any help with that would be appreciated.

Current APKs are in downloads/daily

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