[webkit-gtk] hovering-over-link signal and HitTestResult in WebKit2 API
Carlos Garcia Campos
cgarcia at igalia.com
Thu Feb 2 08:37:35 PST 2012
El jue, 02-02-2012 a las 08:21 -0800, Martin Robinson escribió:
> On Thu, Feb 2, 2012 at 5:56 AM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> > WebKitWebView::element-hovered: signal that receives the mouse modifiers
> > and a WebKitWebElement object.
> > WebKitWebElement could be similar to HitTestResult in wk1 API:
> This seems like a nice API, but I would still suggest using
> WebKitHItTestResult for accuracy sake.
And the signal name?
> This object is actually
> something other than an element.
The problem I see with HitTestResult (which is not exposed by other
ports AFAIK) is that it makes me think there's a way to request a hit
test, which is not possible (at least in this moment) in WebKit2.
HitTestResult is the result of a Hit test, but here we are emitting a
signal when the mouse mover over something (called element everywhere).
> > WebKitWebElementContext: with flags DOCUMENT, LINK, IMAGE, MEDIA,
> > SELECTION, EDITABLE
> > gboolean webkit_web_element_is_document();
> > gboolean webkit_web_element_is_link();
> > gboolean webkit_web_element_is_image();
> > gboolean webkit_web_element_is_media();
> > gboolean webkit_web_element_is_selection();
> > gboolean webkit_web_element_is_editable();
> > That just checks the flags, so more than one can return TRUE for the
> > same element like an image that is a link.
> Notice here that it can be a selection. In WebKit a selection may
> contains many elements. I believe this is also the case with Document.
> An Element is a subclass of Node and a Document is a subclass of Node,
> but Document isn't a subclass of Element.
That's true because you are still thinking in WebKitWebElement as
WebKitDOMElement, but it's not. A WebKitWebElement might contain a
WebKitDOMNode if we manage to have DOM bindings in WebKit2 some day, as
I suggested in my first email.
> So perhaps the WebKitHitTest
> may not even contain an Element at all?
> We had the WebKitHitTestResult in WebKit1 as well.
Because there's a method to request a hit test, so it makes sense to
have a result.
> Later, if we manage
> to get the DOM bindings into the WebKit2 API, I think we can do what
> we did in WebKit1 and make the actual element a property of the
That's exactly what I said in my first email.
> > const gchar *webkit_web_element_get_link_uri();
> > const gchar *webkit_web_element_get_link_title();
> > const gchar *webkit_web_element_get_link_label();
> > const gchar *webkit_web_element_get_image_uri();
> > const gchar *webkit_web_element_get_media_uri();
> > What do you think?
> This API seems awesome, but names like WebKitHitTestResult,
> WebKitMouseTarget, or anything that avoids confusing it with a piece
> of the DOM are far more apt, in my view. The class is actually just a
> description of what the mouse is hovering over, not any single DOM
> element. The WebCore designers are very careful in giving names, so I
> think we can be safe here keeping the name intact.
WebCore uses mouseDidMoveOverElement. If the signal is called
element-hovered, it sounds natural that it receives a WebitWebElement.
But I agree it could be confused with a DOM element, even though all DOM
API is WebKitDOMFoo, but still.
Note that we will use it also in the context menu client API, see this
Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the webkit-gtk