[Webkit-unassigned] [Bug 69753] [GTK] Initial UI client implementation for WebKit2 GTK +API
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Oct 11 06:43:11 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=69753
--- Comment #9 from Martin Robinson <mrobinson at webkit.org> 2011-10-11 06:43:11 PST ---
(In reply to comment #8)
> > The WebKitWebView is the actual widget, but the UIClient controls everything surrounding the WebView. I think it makes sense to split them into two things. For instance, setMenuBarIsVisible has no relation to the WebView widget at all. There are some delegates that I associate with the widget itself such as focus and unfocus -- maybe we can consider having the UIClient just fire signals on the WebView. What do you think?
>
> If we are talking about internal code separation, it's fine with me, what I don't see is a WebKitWebUIClient object like the loader client or the policy client.
Still, it seems odd for the widget to have signals that are about controlling and getting information about its parent window. I think the more conservative aproach is to make UIClient and then later go back and move signals to the WebView if they make sense there. Another approach is to just move some signals there now. The three that you have make sense as WebView signals for instance.
> > Do you mind expanding a bit on how the existence of a page client would change things?
> The web view would be the UI client, while the page object would do the other things the view currently does.
I think of the WebView as the widget that contains the page and the UIClient as controlling the things around it.
> Show makes me think you have to show the view or something, while you don't have to. The first time I saw it I thought it was called everytime you have to show the view for some reason. But it's called only once, to notify that the new view is *ready*.
My undertanding of this API is that the embedder should not actually show the WebView until the show calback has been called. I don't know if the "ready" captures that. Would it be clearer to you as "ready-to-show" ?
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list