[webkit-dev] Question about PopupMenuClient
darin at chromium.org
Thu Jan 7 14:51:22 PST 2010
Chromium actually does something like this. See ChromeClientChromium.
In our case, we have two modes: one where the embedder just has to wrap the
given PopupContainer with a window frame, and in another mode, where the
embedder is responsible for drawing the popup menu.
We are forced to delegate out to the embedding application because of
Chromium's sandbox, which prevents WebKit from directly communicating with
the native widget system (cannot directly create an HWND for example).
In the case where the embedder only supplies framing, the popup menu is
drawn by embedding a ScrollView. Then, all of the drawing happens in
WebCore. You can see this code in PopupMenuChromium.cpp.
On Thu, Jan 7, 2010 at 2:44 PM, Kenneth Christiansen <
kenneth.christiansen at openbossa.org> wrote:
> Hi there,
> A co-worker of mine is implementing the ability to reimplement how popup
> menus (comboboxes) etc will appear from our Qt WebKit API.
> As these UI delegates are per page, we thought about adding a method to our
> ChromeClientQt like AbstractPopupMenu* createPopupMenu(PopupMenuClient*
> client), but currently PopupMenuClient has no access to the page so that we
> can get hold of that.
> I guess that it is not safe to assume that PopupMenuClient::hostWindow() is
> always a Chrome, so would it be acceptable substituting the
> PopupMenuClient::hostWindow() with a PopupMenuClient::page()  method
> and then change the uses to page->chrome() ?
>  easily implemented as return document()->page() instead of return
> Kenneth Rohde Christiansen
> Technical Lead / Senior Software Engineer
> Qt Labs Americas, Nokia Technology Institute, INdT
> Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev