Web vs Native (was Re: HTML5 limitations?)
J. Landman Gay
jacque at hyperactivesw.com
Fri Jul 28 13:53:06 EDT 2017
On 7/28/17 12:01 PM, Mark Waddingham via use-livecode wrote:
> That is the standard process for all enhancement requests. They are
> HIBERNATED until we have the time to evaluate and prioritise - if we
> were to do anything else, we would end up never getting any work done -
> and work we are doing right now is, quite frankly, always more important
> that work that we might do in the future.
> Also, that particular request really doesn't in anyway explain how it
> might work ( sorry Jacque :( ) or, indeed, what that syntax is meant to
> do - so that one has an extra step before moving forward. Actually
> understanding what it is actually about and, indeed, if it even makes
I thought you would figure it out. :) Actually, Richard's request here
on the list was for sample syntax so that's all I suggested. I think we
could discuss here on the list how it might work and then add to the
feature request if we come up with something.
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.
I guess we'd also need a message that tells the script whether the swipe
actually completed fully. If the user changes their mind and doesn't
complete the gesture (the display snaps back,) the script would have to
restore the card or navigation to its original state.
Anyone else have a better idea?
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the Use-livecode