Web vs Native (was Re: HTML5 limitations?)

[Mark Waddingham]

On 2017-07-28 19:53, J. Landman Gay via use-livecode wrote:
> One thought: locking the screen "for swipe effect" might lock the
> screen while any navigation or card changes are made, and then the
> unlock command would track the gesture until mouseUp (or touchEnd.)
> While the tracking is taking place, a fast swipe would do a normal
> visual effect swipe, but a slow drag would draw and redraw the effect
> repeatedly. That would allow both regular swipes and also partial
> swipes that display various degrees of the updated display.

Hehe - okay, let me be honest - I had kinda inferred (just from your 
report and the syntax) that this is what you meant - but I thought it 
better to allow you to articulate your idea without biasing it with my 
interpretation.

So yes - this seems like a neat idea.

First lets consider the 'ideal but with potential yak-shave potential' 
route:

Of course, I think the first thing we would need would be builtin 
gesture support. In this case, this isn't even 'a gesture has happened' 
but 'it looks like a swipe is just starting' (I think at least). e.g. 
swipeBegin / swipeContinue / swipeEnd / swipeCancel.

We'd probably also want a 'swipe' message at the end - i.e. there are 
cases where it is the fact that 'swipe' has happened that you want, and 
not the details of the process it went through (perhaps swipeEnd would 
be fine here, though).

I do like the idea of having the animation of a gesture in the UI being 
tied to the event - its a nice low-code approach for a very common 
problem.

Extrapolating it somewhat, I wonder if it would help solve the 
'pinch-and-zoom' problem. It could even be contextual to the type of 
object (we can probably make pinch-and-zoom of images work nice and 
smoothly without too much effort - but realistically more complex things 
is a little beyond what we could reasonably do right now).

Now lets consider the 'isn't a yak-shave of rather large proportions' 
route:

What specific problem do we really need to solve... i.e. Is card-level 
swiping generally important enough to warrant an approach which isn't 
quite so general (very specific, one might say!)?

The thing here is that we could well consider adding a mechanism which 
is *card* specific (rather than in full generality). e.g. We add a card 
property which states in which directions a card could be swiped, and it 
uses the standard delays, actions of swiping in the various directions. 
Perhaps you get a swipeBegin message when the swipe starts (where you go 
card or whatever - and a snapshot is taken after - i.e. an implicit lock 
for visual effect); and then a swipeEnd / swipeCancel when it is done.

This would be a very high-level bit of functionality, not that 
configurable.

Of course, there is a slight wrinkle here (which might be worth just 
living with for the ability). Screen swiping (which is what we are 
talking about in this specific instance) can be cancelled generally by 
pulling the swipe back. However, in order to get the snapshot of the 
screen (card) which is being gone to (like in visual effects) we 
actually close the current card, then open the next (taking appropriate 
snapshots). This means that we'd end up with either having a case where 
two cards is open (which sounds like a good idea - but believe me it 
really is not, with the way the engine works!); or having to close this 
card, open next card, close next card, open this card.

Is this tradeoff a reasonable one? (I ask you guys, because at the end 
of the day there's no point in us implementing a feature like this if 
you can't actually really use it in your real apps because of a 
technical detail which we can't work around!).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps