The API of WebKitWebView has two remaining quirks. 1) If you want to load content into the view, you currently have the following functions: webkit_web_view_open webkit_web_view_load_string webkit_web_view_load_html_string webkit_web_frame_load_request That is plain chaos right now. So my suggestion instead is the following: webkit_web_view_load_uri webkit_web_view_load_string webkit_web_view_load_request webkit_web_frame_load_uri webkit_web_frame_load_string webkit_web_frame_load_request 2) WebKitWebView has a signal "hovering-over-link" with the random signature (WebKitWebView*, const gchar* tooltip, const gchar* uri). I suggest to remove this in favor of "element-motion". Now the uneasy question is what the signature is going to be. In the long term you will probably have a function looking like webkit_web_view_get_element_at_pos returning a DOM element. Right now we should just try to provide the very most common values, which are from my experience: link_uri image_uri is_control is_editable_control is_password_control As for how to represent that in API I'm hesitating. Suggestions, opinions, ideas welcome, especially from hackers that might have a use for something as fancy as custom context menu items.
(In reply to comment #0) > 1) If you want to load content into the view, you currently have the following > functions: > webkit_web_view_open > webkit_web_view_load_string > webkit_web_view_load_html_string > webkit_web_frame_load_request > > That is plain chaos right now. So my suggestion instead is the following: > > webkit_web_view_load_uri > webkit_web_view_load_string > webkit_web_view_load_request > > webkit_web_frame_load_uri > webkit_web_frame_load_string > webkit_web_frame_load_request I completely agree on this. Alp: what do you think about this API change? If the new API seems ok I can make the required changes and submit a patch for review. > 2) WebKitWebView has a signal "hovering-over-link" with the random signature > (WebKitWebView*, const gchar* tooltip, const gchar* uri). > > I suggest to remove this in favor of "element-motion". Now the uneasy question > is what the signature is going to be. In the long term you will probably have a > function looking like webkit_web_view_get_element_at_pos returning a DOM > element. Right now we should just try to provide the very most common values, > which are from my experience: > > link_uri > image_uri > is_control > is_editable_control > is_password_control > > As for how to represent that in API I'm hesitating. How about something similar to HitTestResult? At the beginning it could contain just the most important things like a get_link_uri() method, later we can add a method returning the DOM element for more advanced uses.
Created attachment 27005 [details] Readjust view and frame loading functions As suggested above, this patch deprecates: webkit_web_view_open webkit_web_view_load_html_string and introduces: webkit_web_view_load_uri webkit_web_view_load_request webkit_web_frame_load_uri webkit_web_frame_load_string For consistency I implemented all functions on the view using the according frame functions.
Could you post the thread init patch somewhere else? or rs=me on that and just commit it.
Created attachment 27039 [details] Readjust view and frame loading functions #2 I want for the rubber stamp for the threading change. Updated patch to not include it anymore.
Comment on attachment 27039 [details] Readjust view and frame loading functions #2 2009-02-12 Christian Dywan <christian@twotoasts.de> Reviewed by Holger Freyther. http://bugs.webkit.org/show_bug.cgi?id=17176 [GTK] API: hovering-over-link and webkit_web_view_open /_load_foo * webkit/webkitwebframe.cpp: * webkit/webkitwebframe.h: * webkit/webkitwebview.cpp: * webkit/webkitwebview.h: Introduce webkit_web_frame_load_uri, webkit_web_frame_load_string, webkit_web_view_load_uri and webkit_web_view_load_request and unify implementations.
Created attachment 28030 [details] Support file paths in _open for compatibility As discussed, webkit_web_view_open used to support local paths until very recently and some applications rely on this. So this patch adds a test if the string is actually a local path. We are not changing webkit_web_view_load_uri because that function is new and we don't really encourage this kind of "guessing" on WebKit's side. I tested it with devhelp, which doesn't show any content anymore due to this regression. Another example would be liferea.
(In reply to comment #6) > Created an attachment (id=28030) [review] > Support file paths in _open for compatibility Looks good to me, and is release critical in my opinion - we need to get this in before we release.
Comment on attachment 28030 [details] Support file paths in _open for compatibility Okay, you might want to do undo my change to open the results of the webkit tests as well.
2009-02-28 Christian Dywan <christian@twotoasts.de> Reviewed by Holger Freyther. * webkit/webkitwebview.cpp: Let webkit_web_view_open add file:// if a locale path is passed for compatibility, since we used to support that.