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

[bugzilla-daemon at webkit.org]

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





--- Comment #20 from C Anthony <anthony at xtfx.me>  2012-02-16 03:14:55 PST ---
[for implementation RFC, please see end!]

... i have spent everyday on this since reporting -- tracing webkit/gobject, rebuilding the appropriate libs with debug symbols, stepping the marshal call chain in [py]gobject ...

... i'm happy to report that i've walked the complete py->webkit->py process, can now write C/C++ with [reasonable] success, and even had to deal with some oddities arising from using C within C++ compiler ...

... BUT ENOUGH ABOUT MY QUEST :-), i have successfully called remove_event_handler from python!  YAY!

no suitable patch ATM (tomorrow), but here are the 5-steps to freedom:

1) adapt add/remove_event_listener to use GClosure
2) write factory function: (add to iface?)

GClosure * [...]_create_event_listener (GCallback*, [...]);

3) ^^^ MUST allocate in C (transfer full)
4) pass returned (or any) GClosure to add/remove_event_listener
5) PROFIT!!!

... as the object is pre-allocated by C, then marshaled back to Python with pre-existing pointer, it is properly recognized by removeEventHandler()!

i really like the GClosure approach because it handles several details for you, and allows for identical signatures on add/remove_event_listener.  also, pygobject still allows you to pass a regular callable [wrapped, *unremoveable*], or passthru a native GClosure [removeable].

... see:

https://mail.gnome.org/archives/python-hackers-list/2012-February/msg00028.html

... for more information why (could possible be fixed, but unlikely, and in some cases not possible).  GClosure is the proper type for the job.

------------------------------------------

[THE RFC-esque SECTION]

while the above works, it's awkward at best -- segfaulty at worst -- to work with the native GClosure from language bindings.  i propose these solutions:

A) [preferred] CREATE WebKitDOMEventListener TYPE

this type will accept a single GClosure/GCallback, and can be subsequently bound to (PLURAL?! ;-) events and/or DOMNodes.  stores an internal ref to bound nodes (via get/set_data?).  has method to [un]bind per DOMEventTarget, or all targets.  could be added to DOMEventTarget Iface for implicit self passing?  GClosure lifetime linked to listener lifetime == auto destroy/cleanup for everyone! hooray!

ADDTL: if we use GClosure, C API users to would not *have* to use WebKitDOMEventListener.  low overhead for all -- bindings could link one high-level callable to several/all WebKit-level handlers (my use case actually *prefers* a SINGLE entry point).

B) [good] STORE gpointer TO LISTENER OR HANDLER ON DOMEventTarget

may require *_full variants, or new generic function that accept gpointers.  store pointer to GObjectListener on DOMEventTarget, eg ...

g_object_set_data(target, {key-from-user-or-???}, &listener)

C) [unknown] USE SOME OTHER WAY BASED ON get/set_data()

Python, and likely(?) other introspect-capable langs, can access pointers stored via g_object_set_data() very easily ... Python can't actually do anything with it (which is why WebKitDOMEventListener is the best choice IMO), but it could be used to unbind related listeners.

D) [non-optimal] CREATE *_full VARIANTS (RETURN/ACCEPT)ING OPAQUE KEYS

this is really more of a workaround than anything else, and breaks the expected API defined by (W3C?) DOM, alas, it's better than no event handling at all:

int webkit_dom_event_target_add_event_handler_full ([...]) {
    gboolean ret = webkit_dom_event_target_add_event_handler([...]);
    if (ret) return (int) &handler;
    return ret;
}

return handler address for use as unique key (or ???, if advantageous); pass same key to *_remove_event_handler_full.  rename by annotation to trim _full suffix.

------------------------------------------

with the exception of (D), the others maintain current return types.  i reeeeallly really like A, for maaaany many reasons -- primarily because it's the most integrated/natural -- the other feel pretty increasingly hacky ... also, (A) would be generally useful for *ALL* users, AAAND all objects are properly linked/chained/destroyed/GC'ed without our help.

... thoughts??? i want to begin writing the solution immediately in the AM, and would love some feedback ASAP!

apologies for the length, i've been at this for days on end, and wanted to be thorough ... thanks much! you guys are the bestest :-)

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