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

[Carlos Garcia Campos]

Looking at liferea code I've noticed that they use
WebKitWebView::hovering-over-link signal (ephy uses it too). This signal
comes from ChromeClient::mouseDidMoveOverElement() and I was wondering
whether it would be useful to expose it as a general signal in the API,
instead of just for links. ChromeClient::mouseDidMoveOverElement
receives a HitTestResult, in WebKit1 we are checking whether it's a link
or not and then emitting WebKitWebView::hovering-over-link in case it's
a link. In WebKit2 mouseDidMoveOverElement is a callback of the UI
Client, that also receives a HitTestResult, so what do you think about
exposing WebKitWebView::hovering-over-element?

That also made me think about how to expose HitTestResult in the API. In
WebKit1 it's only used by webkit_web_view_get_hit_test_result() (it
sounds like a getter, but it actually performs a hit test and returns
the result). In WK2 there's no API to make a hit test from the UI
process, and I'm not sure it's actually needed. However, I think a
HitTestResult object can be useful in the API, probably with a different
name WebKitWebElement or something like that. This could be passed as an
argument to the WebKitWebView::hovering-over-element signal, and it
could be used for the context menu API. 

We could use a similar approach than WK1 HitTestResult object, it has
flags to get information about the hoevered thing (whether it's a link,
or image, or text selected, whether the area is editable, etc.) and the
uri or the image, link or media. It also has the inner node, we can add
later once we have DOM bindings in WK2. 

What do you think?
-- 
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/20120127/a136ffa2/attachment.bin>