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