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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
