[Webkit-unassigned] [Bug 68074] [GTK][WEBKIT2] Add support for title property in WebKitWebView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=68074





--- Comment #6 from Nayan Kumar K <nayankk at motorola.com>  2011-09-29 23:57:57 PST ---
(From update of attachment 109188)
View in context: https://bugs.webkit.org/attachment.cgi?id=109188&action=review

>> Source/WebKit2/UIProcess/API/gtk/WebKitWebLoaderClient.cpp:132
>> +}
> 
> This callback should emit a signal like the other callbacks, and the view can just connect to it to update the title. That way we don't private API to notify the view.

If I understood correctly, this would mean that, applications can connect to 'title-change' signal on WebKitWebLoaderClient and can be notified when title changes. Also, since WebView in turn notifies about the change in 'title' property, application might get redundant notification if they connect both to 'title-change' signal on WebKitWebLoaderClient or 'notify:title' on WebView. I think, our API's should restrict redundancy. What do you say?

>> Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:35
>> +#include <wtf/text/WTFString.h>
> 
> You are using CString, so include CString.h instead.

I use String also, in webkit_web_view_get_title function.

>> Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:308
>> +    return priv->title.data();
> 
> We are already notified when the title changes, we shouldn't need to check it here again. Or can it change after document is loaded?

I think you are right, WebKit should notify if there are any change in the title (even after the document loads). I think its fair enough to assume that this function gets triggered only upon title change.

>> Tools/ChangeLog:10
>> +
> 
> I wouldn't change the GtkLauncher code. We added this GtkLauncher2 when we wanted to use the same api than webkit1, ideally the same code would work and current #ifdefs were just provisional until new api was added. That's not the case anymore, and we don't want GtkLauncher code with a lot of #ifdefs to support both wk1 and wk2. For now, it's better to add unit tests for every new API. Once we have enough API, we will port MiniBrowser to use the GTK+ API and we'll remove webkit2 support from GtkLauncher.

Make sense. I will try to add  unit test for this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.