ozone: Move the factory interfaces into a common target.

ozone: Move the factory interfaces into a common target.

This patch moves:
 * CursorFactoryOzone out of ui/base/cursor/ into ui/ozone/public
 * EventFactoryOzone out of ui/events/ into ui/ozone/public
 * SurfaceFactoryOzone, OverlayCandidatesOzone, SurfaceOzoneCanvas, and
   SurfaceOzoneEGL out of ui/gfx/ into ui/ozone/public
 * FileSurfaceFactory out of ui/gfx/ into ui/ozone/platform/test, since
   the test platform is the only one that uses it.

This patch also builds a separate ozone_base target that includes just the
factories.

BUG=361137
R=bsalomon@google.com, piman@chromium.org, rjkroege@chromium.org, sky@chromium.org, spang@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=278699

[sadrul, 2014-06-07 19:16:28]

What do you guys think?

https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
File ui/ozone/factories/cursor_factory_ozone.h (right):

https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
ui/ozone/factories/cursor_factory_ozone.h:17: typedef void* PlatformCursor;
This is somewhat unclean. We could call this OzoneCursor instead, and update
ui/base/cursor/cursor.h to typedef OzoneCursor PlatformCursor

[rjkroege, 2014-06-09 18:44:45]

On 2014/06/07 19:16:28, sadrul wrote:
> What do you guys think?
> 
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> File ui/ozone/factories/cursor_factory_ozone.h (right):
> 
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> ui/ozone/factories/cursor_factory_ozone.h:17: typedef void* PlatformCursor;
> This is somewhat unclean. We could call this OzoneCursor instead, and update
> ui/base/cursor/cursor.h to typedef OzoneCursor PlatformCursor

What's the one-sentence summary of why we want this?

[spang, 2014-06-09 19:47:37]

On 2014/06/09 18:44:45, rjkroege wrote:
> On 2014/06/07 19:16:28, sadrul wrote:
> > What do you guys think?
> > 
> >
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> > File ui/ozone/factories/cursor_factory_ozone.h (right):
> > 
> >
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> > ui/ozone/factories/cursor_factory_ozone.h:17: typedef void* PlatformCursor;
> > This is somewhat unclean. We could call this OzoneCursor instead, and update
> > ui/base/cursor/cursor.h to typedef OzoneCursor PlatformCursor
> 
> What's the one-sentence summary of why we want this?

This is strictly organizational so the gain would be that we are better
organized.

I don't really have a strong opinion about which way is better.

[kalyank, 2014-06-10 02:07:59]

https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/surf...
File ui/ozone/factories/surface_ozone_canvas.h (right):

https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/surf...
ui/ozone/factories/surface_ozone_canvas.h:26: class OZONE_BASE_EXPORT
SurfaceOzoneCanvas {
I feel Canvas and EGL interface are better under gfx/ rather then factories.

[sadrul, 2014-06-11 13:30:48]

On 2014/06/09 18:44:45, rjkroege wrote:
> On 2014/06/07 19:16:28, sadrul wrote:
> > What do you guys think?
> > 
> >
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> > File ui/ozone/factories/cursor_factory_ozone.h (right):
> > 
> >
>
https://codereview.chromium.org/312393002/diff/120001/ui/ozone/factories/curs...
> > ui/ozone/factories/cursor_factory_ozone.h:17: typedef void* PlatformCursor;
> > This is somewhat unclean. We could call this OzoneCursor instead, and update
> > ui/base/cursor/cursor.h to typedef OzoneCursor PlatformCursor
> 
> What's the one-sentence summary of why we want this?

The SurfaceFactoryOzone will inherit a dependency on ui/events/ through the
platform-window work. So it needs to move out of ui/gfx/ (otherwise we end up
with parts of gfx that depend on events). It made sense to me to move the rest
into a common place.

[spang, 2014-06-17 16:02:19]

lgtm if you rename "factories". Probably to "public"

I don't think factories is a good name. We'll want things that are not
factories. OverlayCandidates is not a factory.

[sadrul, 2014-06-18 23:01:11]

On 2014/06/17 16:02:19, spang wrote:
> lgtm if you rename "factories". Probably to "public"
> 
> I don't think factories is a good name. We'll want things that are not
> factories. OverlayCandidates is not a factory.

I like public too. Done.

[rjkroege, 2014-06-19 14:37:20]

On 2014/06/18 23:01:11, sadrul wrote:
> On 2014/06/17 16:02:19, spang wrote:
> > lgtm if you rename "factories". Probably to "public"
> > 
> > I don't think factories is a good name. We'll want things that are not
> > factories. OverlayCandidates is not a factory.
> 
> I like public too. Done.

public seems like a good choice. it is the interface used by Chrome. I suppose
that we should note this in the website somewhere.

platform here is a synonym for impl? Is it worth changing it?

lgtm

[spang, 2014-06-19 16:11:18]

On 2014/06/19 14:37:20, rjkroege wrote:
> On 2014/06/18 23:01:11, sadrul wrote:
> > On 2014/06/17 16:02:19, spang wrote:
> > > lgtm if you rename "factories". Probably to "public"
> > > 
> > > I don't think factories is a good name. We'll want things that are not
> > > factories. OverlayCandidates is not a factory.
> > 
> > I like public too. Done.
> 
> public seems like a good choice. it is the interface used by Chrome. I suppose
> that we should note this in the website somewhere.
> 
> platform here is a synonym for impl? Is it worth changing it?

hopefully not. "platform" is more informative than "impl"

[sadrul, 2014-06-19 16:15:52]

+piman@ for content/ and ui/gl changes

+sky@ for ui/base/ changes

[piman, 2014-06-19 19:23:29]

lgtm

[sky, 2014-06-19 20:26:38]

ui/base LGTM

[sadrul, 2014-06-19 22:23:51]

+bsalomon@ for DEPS additions to skia/ and third_party/skia

[bsalomon, 2014-06-20 13:21:19]

lgtm

[sadrul, 2014-06-20 13:24:09]

Committed patchset #10 manually as r278699 (presubmit successful).

[sadrul, 2014-06-20 13:27:05]

On 2014/06/20 13:24:09, sadrul wrote:
> Committed patchset #10 manually as r278699 (presubmit successful).

In case this ends up breaking the tree: please note that the landed patch
(patchset 10) is the same as patchset 8, which has green try runs.