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.
Johan Bilien says:
hey, i copied your first version of the code for the hildon home applet. Then ended doing pretty much the same adjustments :) if not a drag the propagate button-press immediately, then motion-notify events, then release when it happens. another small change i made was to order the windows in window->children because they are not garanteed to be in stacking order.
Chris Lord says:
@Johan: I don't suppose you could send your changes to me? The ordering windows sounds interesting and maybe you've done things in a better way to me, so would be interesting to compare notes :)
Johan Bilien says:
Sure! It's all in hildon-desktop svn, in libhildondesktop/hildon-desktop-home-item.c, you'll find the repo from maemo.org. About sorting the children window i could not find a way to do that with gdk and had to call plain X, let me know if you find a 'gtk' way. what happened was that you would sometime select a wimdow which is actually bellow a sibling because it came next in the list.
Chris Lord says:
@Johan: Ah, the re-ordering addition is good, I'll definitely add that to MokoFingerScroll :) I'm not sure if your needs differ, but you probably don't need to check the correct child window on motion events, unless you have widgets that respond to motion events and the widget under the cursor is likely to change. Allocating and traversing the window tree on each motion event is probably quite a performance hit, I'd have thought?
Johan Bilien says:
good point, i do need to forward the motion events to the right underlying window because we have a text entry there whose text is selected during these motion events, but yes checking for which window to send them only on the first such event should be enough. Thanks :)
Any comments?
