MokoFingerScroll event magic

So, spent some time at MobileBarCamp and at work this Monday, re-organising MokoFingerScroll and how it synthesises events. Previously, all events would be intercepted and only after the cursor button was raised would a whole ‘click’ event be synthesised. This is probably how it works in Qtopia, as they seem to have the same problems in their similar widget in Qtopia phone edition (which I recently tried on the OpenMoko phone).
Now, when the mouse is clicked, an enter and a button-down event are sent to the underlying widget – then all following motion events are transformed and forwarded onto that widget too. When the mouse is raised, if scrolling occured, a leave event is sent, then a button-raise event are sent. If no scrolling occured, we want the underlying widget to respond to the click, so we send the button-raise event first, then the leave event.
The up-shot of this is, text selections work in MokoFingerScroll (hah, take that Qtopia! +1 GTK!) and behaviour of widgets in MokoFingerScroll is just overall more reliable and predictable (for example, buttons present their ‘pressed’ state while you hold down on them now). There are still a couple of kinks to work out, but this is much better than the previous method.

]]>

Leave a Reply

Your email address will not be published.