GNOME Bugzilla – Bug 573323
Fix behavior of More... links by adding a Link class
Last modified: 2009-02-26 23:21:03 UTC
We had problems because the More links were reacting on press but other elements were reacting on release. (Often the link would trigger *and* an item.) Just connecting to ::button-release-event on ClutterText gives a stuck grab (since ClutterText gets the press but not the release), so we need more complicated code that we encapsulate into a new class. link.js: new "pseudo-widget" that implements a clickable link. overlay.js: Use Link.Link for the More.. links
Created attachment 129612 [details] [review] Fix behavior of More... links by adding a Link class
(In reply to comment #0) > Just connecting to ::button-release-event on > ClutterText gives a stuck grab (since ClutterText gets the press > but not the release) Should we badger the clutter devs into making clutter's grab handling more like gtk's? (With a stack, and grab-broken notifications) I wanted to implement a "makeClickable" a while back that would make a delegate properly track clicking on an actor (meaning you have to button-press-event on the actor, then possibly leave-event and enter-event some number of times, and then button-release-event in the same actor [without having button-release-evented outside the actor first]) but it wasn't possible to implement that and drag-and-drop orthogonally, for reasons like you describe.
(In reply to comment #2) > (In reply to comment #0) > > Just connecting to ::button-release-event on > > ClutterText gives a stuck grab (since ClutterText gets the press > > but not the release) > > Should we badger the clutter devs into making clutter's grab handling more like > gtk's? (With a stack, and grab-broken notifications) I originally thought that the stuck grab was for some sophisticated reason reasons with hiding actors causing them to lose the release - but actually clutter will happily keep on setting events to the grab widget even if it is hidden, removed from the stage, etc. The problem was much simpler - just that I had overriden button-release and not button-press, so only half the grab handling was happening. What I'd like to see from clutter is implicit grab handling in the toolkit, so that explicit grabs like I have here are not necessary. A grab-broken signal is also probably needed to deal with corner cases like minimizing the stage during a drag. (Such cases seemed like extreme corner cases originally in GTK+, but they came up surprisingly often, necessesitating the signal.) I'm not sure if a grab stack like GTK+'s is actually useful. gtk_grab_add() is used for exactly two thing: - Modal windows - Using together with gdk_pointer_grab() to counteract the evil effects of owner_events=True If Clutter could have only a single form of grab, or better yet, no explicit grabs at all, that would be distinctly better.
Committed with some fixes from Marina on IRC.