[PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

On 13 November 2015 at 01:12, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 12 November 2015 at 23:14, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> On 12 November 2015 at 14:22, Sebastian Kügler <sebas at kde.org> wrote:
>>> On Wednesday, November 11, 2015 20:45:53 Dirk Hohndel wrote:
>>>> On Thu, Nov 12, 2015 at 01:27:54AM +0000, Sebastian Kügler wrote:
>>>> > Heya,
>>>> >
>>>> > Some more work on the mobile version, especially on the divelist and
>>> details.
>>>>
>>>> Great!
>>>>
>>>> > - bugfix for label overflow in dive list
>>>> > - don't create the expensive profilewidget for every frame painted by the
>>> item
>>>> > - kill warnings due to conditional build of subsurface-mobile (#0006)
>>>> > - other cleanups (#0001, #0003)
>>>> > - further layout and styling improvements (all the other patches)
>>>>
>>>> It's coming along. How hard will it be to swipe sideways from dive to dive
>>>> when in dive detail mode? So I tap on one of the dives and I just swipe
>>>> left and right to get to the previous / next dive instead of having to go
>>>> back to the dive list between dives?
>>>
>>> Not entirely trivial as the dives are currently not items next to each other.
>>> Adding previous/next in general shouldn't be too hard, and we could hook it up
>>> to swipe gestures, but it won't look completely natural since we're not having
>>> dives as separate items next to each other. I'll give it some more thinking.
>>>
>>
>> hello,
>>
>> here is a concept with some QML source code (attached), which can help
>> you get started.
>> basically you need two 2 dive containers (dive details) - the current
>> one which is displayed and another one which is the one which comes
>> after the user swipes.
>> the one which comes as new, can be populated with data on the go. if
>> this is slow, some sort of buffering is an option - e.g. 2 dives ahead
>> and 2 behind.
>>
>> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept.gif
>>
>> what i don't like in this experiment is that i have a SwipeArea that
>> handles the swipe gestures, inside a Flickable and the 2 Dives are
>> inside the SwipeArea. normally you would want a Flickable per Dive,
>> because if the user Flicks a dive (say, to look at the dive notes at
>> the bottom) and then decides to swipe to the next dive the next dive
>> Flickable contentY should be at 0, while the old Dive flickable
>> contentY should be where the user left it.
>>
>> i couldn't get a Flickable inside a SwipeArea to work - no matter the
>> usage of preventStealing and propagateComposedEvents.
>> my current solution is to simply reset the single Flickable contentY
>> to 0 on each swipe, which creates a bit of a glitch.
>>
>
> alright...
>
> so here is the visual of the working POC:
> https://dl.dropboxusercontent.com/u/1627980/subsurface/mobile_dive_details_concept2.gif
>
> i restructured the classes a little and now it works the following way:
> - one DiveContainer that defines a navigation callback (i.e.
> left/right) and includes 2 Dives
> - each Dive contains a SwipeArea inside a Flickable. the actual dive
> details are inside the SwipeArea itself.
>
> this is a workaround as i would have preferred to have one SwipeArea
> over the whole DiveContainer and not for each Dive; the solution is
> tolerable as long as we don't have thousands of Dive instances. one
> Flickable per Dive is desired though, like seen in the visual/GIF.
>
> attached is the updated source (with comments this time).
> hope that helps, Sebastian.
>

latest iteration of the test project here.

in the previous version stuff inside the SwipeArea was not clickable -
so we can't have a dive details pane with buttons inside of it, which
obviously isn't acceptable.
the challenge here is that we have a scroll area (Flickable), inside
of which there is an area which captures swipes (SwipeArea) and inside
of it there could be buttons.
...a bit of a complicated mess, but it's doable in QML.

this modification adds single touch support for that via tracking if
the mouse is still over the last pressed element  - e.g. see
'diveDetailsMouseArea' in DiveDetails.
if so, the Dive class captures the click and emits the clicked()
signal to 'diveDetailsMouseArea'
there could be better solutions, but i don't know of them.

this allows the the user to click, say on the dive details to execute
some action, while he/she can still swipe or flick/scroll the dive.

i've also cleaned up the SwipeArea a little.

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface_mobile_swipe_test3.zip
Type: application/zip
Size: 10209 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151113/8668ed9f/attachment.zip>