[PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

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.

lubomir
--

P.S.: QML+ JS is fun!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface_mobile_swipe_test2.zip
Type: application/zip
Size: 9618 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151113/e2ac9234/attachment-0001.zip>