<p dir="ltr"><br>
On 1 Dec 2015 01:27, "Sebastian Kügler" <<a href="mailto:sebas@kde.org">sebas@kde.org</a>> wrote:<br>
><br>
> Hi Rick,<br>
><br>
> On Monday, November 30, 2015 11:33:51 PM Rick Walsh wrote:<br>
> > On 30 November 2015 at 15:57, Dirk Hohndel <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> wrote:<br>
> > > Sebastian and Marco (welcome to the team, btw):<br>
> > ><br>
> > > Awesome. The jump forward of the mobile UI is stunning. It's fun to read<br>
> > > through the commits and see the two of you work together.<br>
> > ><br>
> > > Thanks for the time and effort spent on Subsurface-mobile this weekend!<br>
> > ><br>
> > > The commits have a tiny bit of back-and-forth in them (some times things<br>
> > > get added and then later deleted... maybe the various syncs with<br>
> > > mobilecomponents could be merged into one...) but instead of spending time<br>
> > > to artificially rewrite history into something more pleasing I figured<br>
> > > "what the heck, this is awesome" and left them untouched from what you had<br>
> > > in your branch. And since you didn't touch compiled code (except for<br>
> > > adding the //imports) I didn't see any concern in doing this, anyway -<br>
> > > this is truly just moving the mobile UI forward.<br>
> > ><br>
> > > On Mon, Nov 30, 2015 at 02:35:49AM +0000, Sebastian Kügler wrote:<br>
> > > > Pull again. We did a whole bunch of fixes in the components and the<br>
> > > > applications. The regressions that you saw should be fixed, at least the<br>
> > > > one we saw as well.<br>
> > ><br>
> > > Yes, most of the issues I saw are addressed in master now. New Android<br>
> > > APKs have been uploaded for testing. Those of you with access to an<br>
> > > Android device: seriously, check this out.<br>
> ><br>
> > I took the bait, and installed the latest apk (4.5.2.315) from the daily<br>
> > download page on my Galaxy S6 and had a play.  It really is looking great.<br>
><br>
> Thanks!<br>
><br>
> > I did come across a few bugs you may or may not be aware of yet:<br>
> ><br>
> > When loading dives from the cloud file, existing dives are duplicated in<br>
> > the dive list (see attached screenshot), but after closing the app and<br>
> > re-opening, the list is as it should be.<br>
><br>
> That's weird, haven't seen it before. What I do notice is that after setting<br>
> up a fresh account and downloading the dives, the startpage doesn't disappear<br>
> (which suggests that no dives are in the model). We'll have to look into it.<br>
><br>
> > I managed to crash the app by:<br>
> > (1) selecting a dive that didn't already have 'suit' data<br>
> > (2) tapping on the 'suit' entry to go into edit mode<br>
> > (3) hitting back to exit edit mode (without adding anything)<br>
> > (4) hitting back to return to dive list<br>
> > (5) selecting another dive in the list<br>
> > (6) crash<br>
><br>
> Wonderful. Being able to reproduce a crash goes a long way to fixing it.<br>
> Having the exact steps to reproduce it is really useful.<br>
><br>
> > The drawer (is that what it's called?) button at the base of the screen is<br>
> > shown as a black square over a circle - see screenshot.<br>
> ><br>
> > The GPS entry in the menu on the left of screen (when displayed) also has a<br>
> > black square, where presumably an icon should be.<br>
><br>
> Both should be fixed in latest master. Not sure if Dirk has gotten around to<br>
> updating the APK yet.<br>
><br>
> > As Dirk mentioned:<br>
> > It would be nice if the startup were faster<br>
><br>
> Yes, we discussed this briefly yesterday:<br>
> - it seems that there's some webservice stuff going on before any UI is shown<br>
> (I'm getting traces of SSL communication)<br>
> - same for location services, initializing the location service can take a few<br>
> seconds, so we need to make sure that doesn't happen in the background and the<br>
> user doesn't have to wait for it<br>
><br>
> There's also some room for optimization in the QML bits, but the above two<br>
> seem the main offenders (if my armchair analysis is right, of course).<br>
><br>
> > Sizing the displayed profile is ad-hoc (sometimes rotating the screen, then<br>
><br>
> Not sure what you mean here, could you explain better?</p>
<p dir="ltr">I'll send an email with a few more screen shots, not copying in the list to avoid clogging everybody's inbox with attachments.</p>
<p dir="ltr">On further playing around it appears that on opening selecting a dive (except for the first time), the profile displayed is actually for the the previous dive.  When I rotate the screen, then back, the profile is now for the current dive. Hide profile the unhide also seems to refresh to show the current dive.</p>
<p dir="ltr">Sometimes the profile line just isn't shown at all, but temperature and gas switches are.</p>
<p dir="ltr">Sometimes not all the dive is shown (cropped in horizontal axis).</p>
<p dir="ltr">><br>
> > rotating back seems to get the sizing right, but not always).<br>
> ><br>
> > I didn't test manually adding a dive or the location service.<br>
><br>
> /me neither.<br>
><br>
> Your dive profiles are funny, everything either at max 5m or beyond 40m. :D</p>
<p dir="ltr">Hehe yes, in Melbourne (Australia) we have some great shallow pier dives, and really nice deeper wrecks.  There are also really good reef and wall dives in 15-25m, but if I'm paying to go out on a boat after a 1.5hr drive, mostly I'll go deeper.</p>
<p dir="ltr">The 13 minute dive was a test to see if that pier was worth diving.  There was actually quite a bit of life, but visibility was so bad I couldn't see my backlit dive computer with my arm outstretched.</p>
<p dir="ltr">><br>
> Again, thanks for testing, feedback is very welcome.</p>
<p dir="ltr">Thanks for your work on the app<br>
</p>