I discovered a bug that I’m not sure if it is new of the beta, or it was before.
I discovered a bug that I’m not sure if it is new of the beta, or it was before.
It is related to the setPosition not being correctly set if you are scrolling. This makes that a script that change the position won’t work fine if you are scrolling when it executes, a big problem with the onChange event.
Explanation of the video:
As you can see there are three pages 1,2,3
At the bottom there is a shortcut to my fast run tool, used to run a script directly without the editor (evaluating it)
The script is a timeout that sets the position of the desktop to the second page after 3 seconds, this is used to be able to being scrolling when it executes.
If you just let it execute, it sets the position and everything is ok.
But if you are scrolling, the position is set, but then the container is shown in the same direction as you moved first. The video is a good way to understand it, but if you still don’t do: if you are in the page 0, you scroll to the left half page, and then the script sets the container in page one, you will see it in one and a half page.
Also, as you can see in the last tests, it is ‘moved to the finger’ only when you move the finger, not while it is stop.
Maybe you need to reset the ‘finger movement’ also when setting a new position, but not sure how this is done in android.
(Last note: the bug still persist if you use true as the last parameter in setPosition )
]]>
D5 Creation
< ![CDATA[
There is a functional issue in changing the desktop position in the position changed event. I don’t think there can be a predictable behavior for this: this will start a recursive loop for which a safety check is implemented, but only in some situations. Situations where this check is not implemented (because it cannot be done) will lead to a hanged app (pinch zoom for instance)..
When some scrolling or zooming is managed by the launcher, it has to keep an internal state to handle things correctly (for instance compute stop points, check bounds, snap to page, compute velocity, and so on). If during this operation something else changes some of these data, then I don’t know what should be done. Inertial scrolling and animations could be canceled, but if the user is dragging the screen, I don’t think the drag operation should be stopped. Then a conflict appear.
That’s annoying but setting the position from a script at the same time the app is itself managing a move is undefined.
]]>
< ![CDATA[
Pierre Hébert I’m not saying to stop the dragging, the problem is that after the position change, it is scrolled the same amount the finger has moved.
If you use setPosition(getPositionX(),getPositionY()), if you are scrolling it scrolls the same amount instead of doing nothing.
Can’t you, don’t know, seems difficult, set the finger starting position to the current position when setPosition is used?
]]>
< ![CDATA[
But the problem is that even setPosition(getPositionX(),getPositionY()) is not a NoOp. This will reset the scrolling context, a bit like if acceleration was set to 0, the velocity would drop.
Unfortunately changing the finger down position is not an option.
]]>
< ![CDATA[
Oh, true.
Well, maybe I can check it and manually move the container…something to think 😀
]]>