[Webkit-unassigned] [Bug 77835] [GObject bindings] EventListeners as first-class GObjects: WebKitDOMEventListener

Fri Mar 16 02:29:40 PDT 2012

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

--- Comment #41 from C Anthony <anthony at xtfx.me>  2012-03-16 02:29:40 PST ---
(In reply to comment #33)
> I'll just post some concerns about the API for starters.

is this an indication that my code is complete {expletive deleted}? :-o

if you Zan, and others generously provide additional feedback on design/C/C++ to help me push this thru i would be most grateful ... after 6 wks of nothing else, i'm getting bored/burned, but *need* events for my projects! bah! DOM w/out events is nil ... i will do the work ... but i've implemented it a couple ways here -- and 3x more at home -- need solid path to success, and need to know why/what/must be updated!

i just need to do whatever it takes to wrap this up.  i'm a fairly competent full-time developer w/several langs, but some corners of the C/C++ realm are new and remain fuzzy ... just lmk whats wrong, and whats *really* wrong :-)

thanks to all for time/patience as this moves forward. this is key to extending the most powerful GUI engine in existence to a broad audience

/end rant-vertisement

> > b/Source/WebCore/bindings/gobject/WebKitDOMCustom.h:49
> > +WEBKIT_API WebKitDOMEventListener* webkit_dom_document_create_event_listener(WebKitDOMDocument* self, GClosure* handler);
> 
> Event listener is in no way tied to a document in the DOM spec, meaning creating it should be done through a standalone function - webkit_dom_event_listener_create.

can an EventListener from one doc listen for events in another?  in JS, mainly for DOM but even simple stuff like string comparison, things tend to get very wonky when objects mix cross-doc (doc1.String !== doc2.String, etc).  maybe it doesn't matter for these objects, idk.

... although in IRC you mentioned `ScriptExecutionContext` was a Document or Worker -- this suggests to me that `handleEvent` is in fact tied to a doc/context (otherwise how does stuff like "current propagating event" make sense?) AFAIK you never "naturally" recieve events across [i]frame, you have to first set the context/root to that window (JS again, my experience)

> I'm reiterating ideas previously written in comment #22 - webkit_dom_event_listener_create would take in a WebKitDOMEventListenerFunc, gpointer to a data and a GDestroyNotify callback. As far as I am concerned, this is the most optimal solution. Using a GClosure is just another unnecessary step that should be avoided if possible.

after doing a ton of work with this i cannot stress enough that a GClosure is the optimal and ideal solution.  i adds *minimal* work for a C developer, if really any at all, and in turn works splendidly with existing all binding tools.  in pygobject, with triples, i could not control the refcount -- it increases monotonically every time the listener fires -- no way to destroy ...

... it could very well be a bug with pygobject, or annotations, but again, these problems arise from trying to marshall + coordinate + manage 3 *independent* objects that *do not have any real relation whatsoever* ... GClosures purpose is to avoid these very issues! it does so with much less effort and code than i've written in supporting triples.

if GClosure *really* can't be accepted, then IMO it's crucial the API be split to accommodate (create/create_with_closure) because it's flat-out stable and hassle free for higher langs.  both interfaces must accept only a single parameter on creation, GCallback or GClosure, respectively, and accept a single Event on invocation (+context??..).  the `userdata` param currently in use breaks the DOM spec, and should be omitted; those who need it's facilities can simply use a GClosure.

... buuut why not just sidestep the redundancy and use GClosures exclusively?  We can whittle the original patch as needed, but this detail should persist.

> > b/Source/WebCore/bindings/gobject/WebKitDOMCustom.h:58
> > +WEBKIT_API void webkit_dom_event_listener_set_handler(WebKitDOMEventListener* self, GClosure* handler);
> 
> The DOM spec does not allow these sorts of manipulations on an event listener, and I am of a very strong opinion that we shouldn't neither.
> 
> [...]
> 
> Ditto.

as we discussed in IRC, i still maintain this would be incredibly useful for not just Python/higher langs, but *especially* C.  hotswappping N handlers with a single pointer swap is atomic and cheap ... however, at this point i'm mostly indifferent, and i do/respect understand your reasoning.

anyone else?

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

the main piece i'm adament about is GClosures being used exclusively or at least prominently ... they *really do remove complexity* at every level.

also, contrary to v1, i disabled the attribute listeners because i _really_ need to get a working version of this stabilized/landed; attrib can come later if wanted...

^^^^^ and i misquoted in previous comments ... the GIR file BLIMPS to over 10x, ~40,000K lines, with attrib EventListeners enabled!  i no longer think it's worthwhile, as they are from HTML4, and events are already 100% exposed.

apologies for the length, or any perceived terseness, neither were intentional -- just a bit weary and in dire need of a couple guiding lights! *hint* *hint* ;-) ;-)

so, what can i do to land this beast?  what needs explain/explore/verify?  i implemented a couple other ways as well, one making great use of GValues to support Gclosure and GCallback on same interface, and the other using a manual ::kit() impl in WebKitDOMBindings to do some magic ... but IMO, what you see here are the cleanest, most succinct solutions, after weeks of experimentation.

please comment! thanks so much for your time!. and thanks for all the fish too -- delicious!

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