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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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