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 
> sense.

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 mailing list