On Mon, Nov 30, 2015 at 02:27:07PM +0000, Sebastian Kügler wrote: > That's weird, haven't seen it before. What I do notice is that after setting > up a fresh account and downloading the dives, the startpage doesn't disappear > (which suggests that no dives are in the model). We'll have to look into it.
When I saw it it was an issue with how the model was populated. So the dive list was correct, but the model ended up adding each dive twice. > > I managed to crash the app by: > > (1) selecting a dive that didn't already have 'suit' data > > (2) tapping on the 'suit' entry to go into edit mode > > (3) hitting back to exit edit mode (without adding anything) > > (4) hitting back to return to dive list > > (5) selecting another dive in the list > > (6) crash > > Wonderful. Being able to reproduce a crash goes a long way to fixing it. > Having the exact steps to reproduce it is really useful. > > > The drawer (is that what it's called?) button at the base of the screen is > > shown as a black square over a circle - see screenshot. > > > > The GPS entry in the menu on the left of screen (when displayed) also has a > > black square, where presumably an icon should be. > > Both should be fixed in latest master. Not sure if Dirk has gotten around to > updating the APK yet. The .315 APK is built from the latest master. You can always do git describe it will show you the number of commits since the last tag. > > As Dirk mentioned: > > It would be nice if the startup were faster > > Yes, we discussed this briefly yesterday: > - it seems that there's some webservice stuff going on before any UI is shown > (I'm getting traces of SSL communication) Yes, that's opening the cloud file. But at that time the UI should be initialized already since loading the file is called from the UI support code. I need to look a little closer to see if there is an ordering issue (there definitely is for the desktop UI, that's on my todo list to fix - which is why I thought I took care of NOT having the same problem in the mobile UI). > - same for location services, initializing the location service can take a > few > seconds, so we need to make sure that doesn't happen in the background and > the > user doesn't have to wait for it Yes, this is right now on the constructor, but again it is set up so that it should not wait for the first fix (my first implementation did that). > There's also some room for optimization in the QML bits, but the above two > seem the main offenders (if my armchair analysis is right, of course). Seems entirely likely. > Your dive profiles are funny, everything either at max 5m or beyond 40m. :D The number of seriously hard core tech divers here can be intimidating... /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
