[webkit-dev] On IDL files, events and writing DOM bindings

Xan Lopez xan at gnome.org
Tue Aug 10 23:39:56 PDT 2010

On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler <darin at apple.com> wrote:
> The bindings do not expose events directly, thus the IDL files don’t show the events. The IDL files only show functions and attributes on the various objects. Events are neither functions nor attributes. For the bindings I am familiar with, there is no list of events and so nothing to be generated from the IDL. The event names, as with tag names, are string constants.

Interesting. For the GObject bindings I'm actually exposing the events
directly. Eg, you are able to do:

g_signal_connect(image, "click-event", callback, NULL);

and callback will be called when the image is clicked, with an Event
object as a parameter. The wrapping for the Events comes from the IDL
file that exists for each type of event (Event.idl and its

> You mentioned the ended attribute in HTMLMediaElement. This is a boolean attribute, and not an event. It happens to have the same name as an event, but there is no direct connection between the event and the attribute.

Right, I was aware of the distinction. Maybe I failed to express
myself properly here, my only doubt was really why there was no
reference to the event in any IDL file, which has already been

> You asked:
>> is it possible to know which Events are defined for each class just from the IDL files
> Events are not defined for classes. The engine can send events to any EventTarget, and the IDL files and the bindings have nothing to say about which events the engine will send to which objects.


I think the only solution that makes sense for the bindings (at least
the GObject ones, where you *do* have to tell a class which kind of
events/signals it can receive or emit), is to define every possible
type of event in the most basic class that is an EventTarget (say,
Node). In this way you'll be able to connect to the event delivery
signals or manually dispatch and event to any node or any of its
subclasses, both perfectly valid things to do.



>    -- Darin

More information about the webkit-dev mailing list