pre beta test subsurface-mobile 689

[Dirk Hohndel]

On Thu, Jan 21, 2016 at 05:25:46PM +0100, Jan Mulder wrote:
> >>on the most recent changes with that respect. First, running on the desktop,
> >>I can easily crash the app by pulling the divedetails slider. Difficult to
> >Can you explain in a bit more detail what exactly you mean by "pulling the
> >divedetails slider"? Do you mean the horizontal bar at the bottom of the
> >screen?
> 
> Yes, the horizontal bar at the bottom. I mean with "pulling the slider".
> Focus with the mouse and hold it while sliding to the right. Basically, this
> overfloods the call of setDiveId, as in very quick selecting different
> dives.

OK, so this is a use case that would be much harder to create on the
mobile device as you can move between dives much more rapidly with that
slide than by swiping on the device.

> >Which OS are you running? Which version of Qt are you running with (btw,
> >that's in the log display that you can get to from the left drawer under
> >Developer)?
> Arch Linux, latest pacman -Syu, and the Qt stuff from the Arch repository.
> Version 5.5.1.

Exact same as I use, so I should be able to reproduce it. Maybe it's
something about your dive data in combination with the specific user
interaction. Maybe there is something about your dives that stresses the
rendering in a certain way.

> >I thought that was implemented in Rick's change to abstract out the
> >SubsurfaceButton.qml but didn't pay much attention to that detail. Yes,
> >the button should change when pressed - different color or something. Jan,
> >would you like to try to play with this? This is a really nice and simple
> >way to get your feet wet with QML (and you clearly are already building
> >your own on the desktop).
> Ok, I will give this a go. I already did Henriks simple "back to divelist"
> (but I see something I still do not like and I do not want to spoil the fun
> :-)

Excellent. I sound like a broken record, but we really benefit when more
people contribute.

> >>The editing itself. The notes box is bigger than the screen. So when
> >>starting to enter text, you run out of screen and do not see what you type.
> >Really? What device? What screen resolution?
> 5" screen portrait orientation. 720x1280 pixels.
> 
> >>Re-positioning of the edit screen does not work (it slides back when
> >>swiped). Basically, re-styling the edit screen would solve this (labels on
> >>top instead of in front).
> >But that uses a lot more vertical space overall. I'll play around with the
> >options there to optimize. Maybe do this just for the notes..
> I agree that the main "problem" here is the notes.

OK, that's really easy to play with. I'll give it a go.

> >Yes and I have no idea what to do in that case. I want to show the dive
> >list from cache right away. That's just a much better user experience. But
> >then after the sync from the cloud is completed, what do we do if there's
> >a change?
> I agree that this is a dilemma. Is is just the lack of visual feedback here
> that causes me to click some more times before realizing that it is just
> busy. I am not really into UI design, but "greyed out" or "wait cursor"
> spring to mind.

The problem with that is that if your connection times out (island with
really slow network) then the program would be unusable for a very long
time. It's supposed to allow you to interact while trying to connect to
the cloud server. Maybe something isn't working right there. I need to sit
in one of the really really poor reception places around here and simulate
a slow network :-)

> Agreed and I file these as enhancements. However, i think the especially the
> first one (autocomplete) will result in not using the app for real. Entering
> at the divesite correctly (proper spelling of names) will not happen for me,
> and just trying results in lot of work later to correct it. But again,
> version 2 stuff.

Actually, I disagree. Just fill it in real quick and clean it up on the
desktop. I think that's a much more likely scenario.

Admittedly I am one of the people who don't consider phones or tablets
reasonable devices for data input. And apparently there are people writing
their dissertations on an iPad. So who knows, I may be way off. But given
how hard it has been to get this even remotely right on the desktop, I
really don't want to deal with it on the mobile device. Even worse, in 30
seconds someone will tell me that we also need to re-implement the whole
f-ing divesite disaster of functionality on the QML UI and then I'll
likely say a bad word. Or maybe even two.

/D