Remove dependency on ui from view_manager.

Remove dependency on ui from view_manager.

This removes unnecessary dependencies like skia, freetype and many others. Instead of using geometry types from gfx, use the simple types already in mojo.

R=ben@chromium.org, sky@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/ed8d84dd3ef77703a215583ac28abb88f5aaae8e

[jam, 2014-10-23 14:57:08]

jam@chromium.org changed reviewers:
+ ben@chromium.org

[jam, 2014-10-23 14:57:09]

This drops the dependencies from

$ gn desc out/Default/ //mojo/services/public/cpp/view_manager:view_manager libs
    gmodule-2.0
    gobject-2.0
    gthread-2.0
    rt
    glib-2.0
    fontconfig
    freetype
    pangocairo-1.0
    pango-1.0
    cairo
    nss3
    nssutil3
    smime3
    plds4
    plc4
    nspr4
    dl
    X11
    Xcomposite
    Xcursor
    Xdamage
    Xext
    Xfixes
    Xi
    Xrender
    Xss
    Xtst
    asound


to

$ gn desc out/Debug/ //mojo/services/public/cpp/view_manager:view_manager libs
    gmodule-2.0
    gobject-2.0
    gthread-2.0
    rt
    glib-2.0

[jam, 2014-10-23 14:58:13]

+mojo-reviews since this checkout doesn't have the update to codereview.settings

[Ben Goodger (Google), 2014-10-23 15:11:08]

lgtm

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
File mojo/examples/wm_flow/wm/frame_controller.cc (right):

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
mojo/examples/wm_flow/wm/frame_controller.cc:140: restored_bounds_ =
view_->bounds().Clone().To<gfx::Rect>();
this is the weirdness

[jam, 2014-10-23 15:19:53]

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
File mojo/examples/wm_flow/wm/frame_controller.cc (right):

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
mojo/examples/wm_flow/wm/frame_controller.cc:140: restored_bounds_ =
view_->bounds().Clone().To<gfx::Rect>();
On 2014/10/23 15:11:08, Ben Goodger (Google) wrote:
> this is the weirdness

I agree. Let me check with others why the To method is only on RectPtr and if
it's ok to also add it to the generated Rect.

[jam, 2014-10-23 20:49:48]

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
File mojo/examples/wm_flow/wm/frame_controller.cc (right):

https://codereview.chromium.org/658923003/diff/20001/mojo/examples/wm_flow/wm...
mojo/examples/wm_flow/wm/frame_controller.cc:140: restored_bounds_ =
view_->bounds().Clone().To<gfx::Rect>();
On 2014/10/23 15:19:53, jam wrote:
> On 2014/10/23 15:11:08, Ben Goodger (Google) wrote:
> > this is the weirdness
> 
> I agree. Let me check with others why the To method is only on RectPtr and if
> it's ok to also add it to the generated Rect.

I've made the generated struct have a To() method to match the Ptr version, and
it clears this up.

[jam, 2014-10-23 20:52:48]

jam@chromium.org changed reviewers:
+ sky@chromium.org

[jam, 2014-10-23 20:52:48]

+sky for latest patchset (3) since ben is gone

[sky, 2014-10-23 21:05:38]

LGTM

[jam, 2014-10-23 21:27:13]

Committed patchset #4 (id:60001) manually as
ed8d84dd3ef77703a215583ac28abb88f5aaae8e (presubmit successful).

[darin (slow to review), 2014-10-24 04:37:14]

darin@chromium.org changed reviewers:
+ darin@chromium.org

[darin (slow to review), 2014-10-24 04:37:15]

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
File mojo/converters/geometry/geometry_type_converters.h (right):

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
mojo/converters/geometry/geometry_type_converters.h:46: struct
MOJO_GEOMETRY_EXPORT TypeConverter<RectPtr, gfx::Rect> {
it seems like this should be expressible in terms of the newly minted
TypeConverter<Rect, gfx::Rect> class. we should be able to write a generic
flavor of TypeConverter<StructPtr<S>, U> that utilizes TypeConverter<S, U>.
probably something to explore as a separate CL.

[jam, 2014-10-24 17:15:05]

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
File mojo/converters/geometry/geometry_type_converters.h (right):

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
mojo/converters/geometry/geometry_type_converters.h:46: struct
MOJO_GEOMETRY_EXPORT TypeConverter<RectPtr, gfx::Rect> {
On 2014/10/24 04:37:15, darin wrote:
> it seems like this should be expressible in terms of the newly minted
> TypeConverter<Rect, gfx::Rect> class. we should be able to write a generic
> flavor of TypeConverter<StructPtr<S>, U> that utilizes TypeConverter<S, U>.
> probably something to explore as a separate CL.

I had tried to do this but couldn't figure out one way to access the rect
members for both RectPtr and mojo::Rect. also the construction of the return
type, and how it's returned, is different (i.e. "RectPtr rect(Rect::New());" and
"Rect rect;"). Would I need to have some other type as a parameter to the
template which contains this knowledge? Any suggestions or examples to look at?

[yzshen1, 2014-10-27 16:55:18]

yzshen@chromium.org changed reviewers:
+ yzshen@chromium.org

[yzshen1, 2014-10-27 16:55:19]

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
File mojo/converters/geometry/geometry_type_converters.h (right):

https://codereview.chromium.org/658923003/diff/60001/mojo/converters/geometry...
mojo/converters/geometry/geometry_type_converters.h:46: struct
MOJO_GEOMETRY_EXPORT TypeConverter<RectPtr, gfx::Rect> {
On 2014/10/24 17:15:05, jam wrote:
> On 2014/10/24 04:37:15, darin wrote:
> > it seems like this should be expressible in terms of the newly minted
> > TypeConverter<Rect, gfx::Rect> class. we should be able to write a generic
> > flavor of TypeConverter<StructPtr<S>, U> that utilizes TypeConverter<S, U>.
> > probably something to explore as a separate CL.
> 
> I had tried to do this but couldn't figure out one way to access the rect
> members for both RectPtr and mojo::Rect. also the construction of the return
> type, and how it's returned, is different (i.e. "RectPtr rect(Rect::New());"
and
> "Rect rect;"). Would I need to have some other type as a parameter to the
> template which contains this knowledge? Any suggestions or examples to look
at?

(Drive-by comments; no need to wait for my LG.)

I think if we are willing to change the Convert() signature, we could write it
this way:

template<>
struct TypeConverter<StructPtr<S>, U> {
  static Convert(const U& input, StructPtr<S>* output) {
    output->Swap(S::New());
    TypeConverter<S, U>::Convert(input, output->get());
  }
};

And we also need a specialization for InlinedStructPtr<>.
template<>
struct TypeConverter<InlinedStructPtr<S>, U> {
  // Similar to the one above
};