Use WebWidget from the WebKit API. This change also makes...

Use WebWidget from the WebKit API.  This change also makes
use of WebKitClient (replacing WebWidgetDelegate from glue).

The ripple effects of this change are rather large, but most
of the impact is mechanical.

The more interesting changes include:

1- Removing the WebWidget parameter from WebWidgetClient methods.  This didn't
matter at all to RenderWidget or RenderView, but it did cause some changes to
be made to TestWebViewDelegate.  Now, it is not possible to share a delegate
implementation for both the WebView and a popup menu, so I have a second
instance of the delegate owned by TestShell for use with popup menus.

2- Plumbing WebNavigationPolicy in place of WindowOpenDisposition was getting
to be a pretty large change, so I stopped short of deleting WindowOpenDisposition.
That way the Chrome side can remain mostly unmodified.  I then added a mapping
function to convert from WebNavigationPolicy to WindowOpenDisposition.

3- The IME methods on WebWidget were renamed (reviewed separately by hbono), and
there is now an enum to specify the composition command (WebCompositionCommand).

4- I added IPC serialization for WebCompositionCommand and WebTextDirection,
which cleaned up some code that was just using ints in IPC messages.

R=jam
BUG=16234
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=20854

[jam, 2009-07-15 19:52:19]

lgtm

http://codereview.chromium.org/149620/diff/1602/639
File chrome/browser/renderer_host/render_widget_host.cc (right):

http://codereview.chromium.org/149620/diff/1602/639#newcode474
Line 474: ime_string));
nit: the style in this function should match the ones below (i.e. either add as
many parameters to each line to fit 80 chars, or put each separately)

http://codereview.chromium.org/149620/diff/1602/643
File chrome/common/webkit_param_traits.h (right):

http://codereview.chromium.org/149620/diff/1602/643#newcode100
Line 100: struct ParamTraits<WebKit::WebCompositionCommand> {
nit: it seems we can create a template for serializing any enum, and use it here
and below.

[darin (slow to review), 2009-07-15 20:45:18]

http://codereview.chromium.org/149620/diff/1602/643
File chrome/common/webkit_param_traits.h (right):

http://codereview.chromium.org/149620/diff/1602/643#newcode100
Line 100: struct ParamTraits<WebKit::WebCompositionCommand> {
yeah, i had the same thought... it is easy to do with a macro, but i couldn't
find a non-macro way to do something more compact.  any ideas?

if i assume sizeof(int) == sizeof(param_type), then i could make the Read
function one line.  that assumption is probably ok though it is not required by
the spec.

[jam, 2009-07-15 21:54:48]

http://codereview.chromium.org/149620/diff/1602/643
File chrome/common/webkit_param_traits.h (right):

http://codereview.chromium.org/149620/diff/1602/643#newcode100
Line 100: struct ParamTraits<WebKit::WebCompositionCommand> {
On 2009/07/15 20:45:18, darin wrote:
> yeah, i had the same thought... it is easy to do with a macro, but i couldn't
> find a non-macro way to do something more compact.  any ideas?
> 

no not sure (mpcomplete's template fu is better than mine)

> if i assume sizeof(int) == sizeof(param_type), then i could make the Read
> function one line.  that assumption is probably ok though it is not required
by
> the spec.

do you mean by using reinterpret_cast?  from what I read, gcc will use 64 bits
if there are negative + positive numbers.  so maybe it's just safer to leave the
static_cast there sinec it'll cause this problem in the future (unless the
static_cast in the Write function will catch it on its own)

[darin (slow to review), 2009-07-15 22:18:34]

On Wed, Jul 15, 2009 at 2:54 PM, <jam@chromium.org> wrote:

>
> http://codereview.chromium.org/149620/diff/1602/643
> File chrome/common/webkit_param_traits.h (right):
>
> http://codereview.chromium.org/149620/diff/1602/643#newcode100
> Line 100: struct ParamTraits<WebKit::WebCompositionCommand> {
> On 2009/07/15 20:45:18, darin wrote:
>
>> yeah, i had the same thought... it is easy to do with a macro, but i
>>
> couldn't
>
>> find a non-macro way to do something more compact.  any ideas?
>>
>
>
> no not sure (mpcomplete's template fu is better than mine)
>
>  if i assume sizeof(int) == sizeof(param_type), then i could make the
>>
> Read
>
>> function one line.  that assumption is probably ok though it is not
>>
> required by
>
>> the spec.
>>
>
> do you mean by using reinterpret_cast?  from what I read, gcc will use
> 64 bits if there are negative + positive numbers.  so maybe it's just
> safer to leave the static_cast there sinec it'll cause this problem in
> the future (unless the static_cast in the Write function will catch it
> on its own)
>
>
> http://codereview.chromium.org/149620
>


I think there is probably a good cleanup task here to coalesce a bunch of
our
ParamTraits.  We have many others that are just for serializing enums.  I
filed
http://crbug.com/16866 for that.

-Darin