[PATCH] mobile: divedetails page etc. improvements

Lubomir I. Ivanov neolit123 at gmail.com
Thu Nov 12 13:14:51 PST 2015


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.

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface_mobile_swipe_test.zip
Type: application/zip
Size: 2914 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151112/d8fdc118/attachment.zip>


More information about the subsurface mailing list