[Webkit-unassigned] [Bug 77835] [GObject bindings] Missing scope annotations for add/remove_event_listener

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Feb 11 21:27:50 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=77835





--- Comment #16 from C Anthony <anthony at xtfx.me>  2012-02-11 21:27:50 PST ---
Created an attachment (id=126669)
 --> (https://bugs.webkit.org/attachment.cgi?id=126669&action=review)
annotation to override parsed C type

this patch demonstrates using an annotation to override the parsed C type instead of actually changing it everywhere.  AFAICT, pygobject just needs to know ahead of time what the callback should receive, and by default GCallback receives nothing (and this seems to match the intended way to use/register a GCallback .. by casting at last second).  this same idea is used in the Telepathy lib.

with this patch i am able to properly receive events with arguments, however the remove_ method still of course fails.  in other libraries i see the remove_ variant using a gpointer instead of a GCallback ... maybe we can pass both add_ and remove_ this way?  im checking with the #introspection people to see how we can solve this -- i'm curious if there is some way to weakref the callback?  ideally, if the callback is GC'ed in the runtime the listener should simply be removed (i found some hinting to this mechanism in my travels).  maybe this would work when passing gpointers (like userData)?

however, most libraries seem to be side-stepping the issue altogether, with add_ returning a unique/opaque key (some incremented number, whatever), and remove_ accepting that key -- no reference to the actual callback is needed.  while this isn't 100% true to DOM API, imo the inability to enumerate the active listeners and manage them whatsoever is a major shortcoming anyway ...

i'll continue trying to get remove_ to work, but this seems an unobtrusive way to get add_ working.

thanks!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list