In 10.6.5 swiping left on desktop fires “C_SWIPE_RIGHT” and vice versa.
In 10.6.5 swiping left on desktop fires “C_SWIPE_RIGHT” and vice versa. For items “I_SWIPE_LEFT/RIGHT” are send correctly. UP/DOWN also is the same for C an I.
]]>
« Pierre Hébert (Previous Post)
(Next Post) Pierre Hébert I saw you are modifying the app drawer a lot. This is a bug you can fix too. »
D5 Creation
< ![CDATA[
There has been a translation change recently for the German pack, swipe left and right have been exchanged. Could it be related with this change ?
]]>
< ![CDATA[
No, I am not using any language pack.
I set both events Swipe Left and Right for desktop and an item to a simple script (alert(LL.getEvent().getSource());).
Output shows the source C_SWIPE_RIGHT/LEFT inverted for desktop.
]]>
< ![CDATA[
I confirm that there is a label inversion behind this: the event labeled “Swipe right” calls the internal action “swipeLeft” with source “C_SWIPE_LEFT”. It has been messed a long time ago. I could change the source, but this would only add more confusion because “swipeLeft” would remain called by “Swipe right”. The right thing would be to fix the association between the user facing label and the internal action but this is not possible for obvious compatibility reasons.
The mess came from the ambiguity between “swipe from” and “swipe to”.
]]>
< ![CDATA[
Pierre Hébert Please forget about the labels. Set the alert-script for both swipe left and right events (a) on the desktop and (b) on a shortcut. Swipe (right-to-)left on desktop and screen. You’ll get C_SWIPE_RIGHT and I_SWIPE_LEFT. That’s my point. It’s inconsistent. But I agree changing this would break existing code relying on the wrong C_SWIPE_LEFT/RIGHT. Devs would realize this bug anyway and act accordingly.
BTW: why ain’t there swipe-events one can attach to on panels?
]]>
< ![CDATA[
That’s not a compatibility problem with scripts, but one with existing setups: the event “right” is linked with internal action “left”, everything else is ok, so fixing it wouldn’t change scripts only but users setup first.
No swipe on panels because they can scroll and this is not possible to detect safely/easily whether the finger move is a swipe or scroll (panels can include other panels, or scrolling items, recursively).
]]>