mv Source/WebKit/chromium/public to public/webview

mv Source/WebKit/chromium/public to public/webview

This CL moves the public API headers from Source/WebKit/chromium/public to
public/webview. This CL is part of an ongoing project to move all the
externally referenced files into the top-level public directory.

This CL also adds forwading headers in Source/WebKit/chromium/public so that
existing code including these headers won't break. Future CLs will update the
code that includes these forwarding headers to include the real versions
directly.

TBR=jamesr
BUG=239545
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=151725

[jamesr, 2013-06-04 08:11:08]

Can we *please* avoid adding another thing called 'webview' to the tree?  We
have at least 5 different things with this name in the project already, this is
going to be horribly confusing.

Why not public/client ?

[abarth-chromium, 2013-06-04 08:11:10]

Committed patchset #1 manually as r151725.

[jamesr, 2013-06-04 08:12:27]

On 2013/06/04 08:11:10, abarth wrote:
> Committed patchset #1 manually as r151725.

Did you need to rush this?  I haven't seen anything about this name before and
this doesn't match what the linked bug suggests.

[abarth-chromium, 2013-06-04 08:21:10]

On 2013/06/04 08:12:27, jamesr wrote:
> On 2013/06/04 08:11:10, abarth wrote:
> > Committed patchset #1 manually as r151725.
> 
> Did you need to rush this?

Sorry, I didn't see your email.

> I haven't seen anything about this name before and
> this doesn't match what the linked bug suggests.

I'll hold off on updating references to the new name until we decide on a name. 
These CLs just bitrot very quickly.

[abarth-chromium, 2013-06-04 08:23:09]

> Why not public/client ?

No one I've talked with was very excited about "client" as a name.  Part of the
problem is that it doesn't really mean anything.  It's somewhat of a reference
to things like FrameLoaderClient, but those are internal concepts to Blink and
not something that make sense to embedders of Blink.

[abarth-chromium, 2013-06-04 09:11:21]

Running a find in my Chromium tree, I see these webview-related directories:

android_webview
chrome/browser/extensions/api/webview
chrome/browser/webview
third_party/WebKit/public/webview
ui/views/controls/webview

Once we move third_party/WebKit -> blink, this list will look more like:

android_webview
blink/public/webview
chrome/browser/extensions/api/webview
chrome/browser/webview
ui/views/controls/webview

That doesn't seem too bad too me, but maybe I've given up on trying to find a
better name for this directory.  I think it makes sense to refer to this API as
Blink's WebView, which will match the name of the main API in the directory,
blink::WebView.

Similarly, we might call the other webview-related concepts "the Android
WebView" or views::WebView.  We'll probably call the extension API <webview> or
"the WebView tag."

Even if we don't call the directory "webview", we'll still have WebView.h, so
there's not really any getting away from having "yet another WebView"...

[jamesr, 2013-06-04 21:59:49]

On 2013/06/04 09:11:21, abarth wrote:
> That doesn't seem too bad too me, but maybe I've given up on trying to find a
> better name for this directory.  I think it makes sense to refer to this API
as
> Blink's WebView, which will match the name of the main API in the directory,
> blink::WebView.
> 
> Similarly, we might call the other webview-related concepts "the Android
> WebView" or views::WebView.  We'll probably call the extension API <webview>
or
> "the WebView tag."

Some of us have been dealing with that for a year+, and it's confusing as all
get out and not getting any better.  Many people only care about one of these
and just talk about "the webview API" leaving it to those of us who have to live
with more than one to figure out which they mean.

> 
> Even if we don't call the directory "webview", we'll still have WebView.h, so
> there's not really any getting away from having "yet another WebView"...

Yes, but at least we can avoid having a directory.

Sorry but I just can't live with public/webview/ - my brain will pop out of my
skull and leap out the nearest window :(.  Other ideas we thought about at
lunch:

public/web/WebWidget.h
public/blink/WebWidget.h (sadly repetitive)
public/client/WebWidget.h
public/WebWidget.h, since public/platform and public/testing/ are really special
subsets of the overall blink API

[abarth-chromium, 2013-06-04 22:02:58]

On 2013/06/04 21:59:49, jamesr wrote:
> Sorry but I just can't live with public/webview/ - my brain will pop out of my
> skull and leap out the nearest window :(.

Oh my.

> Other ideas we thought about at lunch:

What about public/webpage/WebWidget.h ?

We could event rename blink::WebView to blink::WebPage if you really wanted to
remove the name WebView.  That would match the underlying Core class (Page) in
the same way that WebFrame matches Frame.

[jamesr1, 2013-06-04 22:10:30]

On Tue, Jun 4, 2013 at 3:02 PM, <abarth@chromium.org> wrote:

> On 2013/06/04 21:59:49, jamesr wrote:
>
>> Sorry but I just can't live with public/webview/ - my brain will pop out
>> of my
>> skull and leap out the nearest window :(.
>>
>
> Oh my.
>
>
>  Other ideas we thought about at lunch:
>>
>
> What about public/webpage/WebWidget.h ?
>

That's not bad.

>
> We could event rename blink::WebView to blink::WebPage if you really
> wanted to
> remove the name WebView.  That would match the underlying Core class
> (Page) in
> the same way that WebFrame matches Frame.
>

There's are parallels in chromium code between (Web|Render)(Widget|View),
losing those might be a bit of a bummer.  I just really want to avoid
adding another layer or concept with the same name.

- James


>
>
https://codereview.chromium.**org/16358003/<https://codereview.chromium.org/1...
>

[darin (slow to review), 2013-06-04 22:19:30]

I've long wanted to rename WebView to WebPage as it better parallels Page.
 I think WebKit2 uses the term "<mumble>Page" for a similar concept in
their API as well.  We might even evolve RenderView to be named RenderPage.
 (With out of process iframes, we'll be introducing RenderFrame{Host} by
the way.)

-Darin


On Tue, Jun 4, 2013 at 3:10 PM, James Robinson <jamesr@google.com> wrote:

>
>
>
> On Tue, Jun 4, 2013 at 3:02 PM, <abarth@chromium.org> wrote:
>
>> On 2013/06/04 21:59:49, jamesr wrote:
>>
>>> Sorry but I just can't live with public/webview/ - my brain will pop out
>>> of my
>>> skull and leap out the nearest window :(.
>>>
>>
>> Oh my.
>>
>>
>>  Other ideas we thought about at lunch:
>>>
>>
>> What about public/webpage/WebWidget.h ?
>>
>
> That's not bad.
>
>>
>> We could event rename blink::WebView to blink::WebPage if you really
>> wanted to
>> remove the name WebView.  That would match the underlying Core class
>> (Page) in
>> the same way that WebFrame matches Frame.
>>
>
> There's are parallels in chromium code between (Web|Render)(Widget|View),
> losing those might be a bit of a bummer.  I just really want to avoid
> adding another layer or concept with the same name.
>
> - James
>
>
>>
>>
https://codereview.chromium.**org/16358003/<https://codereview.chromium.org/1...
>>
>
>

[abarth-chromium, 2013-06-04 23:04:47]

Ok, sounds like we should call it public/webpage.

[abarth-chromium, 2013-06-07 06:44:43]

Followup is in https://codereview.chromium.org/16623002