[webkit-gtk] hovering-over-link signal and HitTestResult in WebKit2 API

[Carlos Garcia Campos]

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
> WebKitHitTestResult.

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
bug https://bugs.webkit.org/show_bug.cgi?id=77208

> --Martin
> 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120202/b1fd50a4/attachment.bin>