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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
