Replace info_bubble::BubbleArrowLocation with views::BubbleBorder::Arrow

Replace info_bubble::BubbleArrowLocation with views::BubbleBorder::Arrow

Both serve the same purpose. Refactor cocoa code to use the views enum.

BUG=476662

[hcarmona, 2015-06-03 00:20:12]

hcarmona@chromium.org changed reviewers:
+ rsesek@chromium.org

[hcarmona, 2015-06-03 00:20:13]

I'm trying to replace the cocoa specific enum in bubbles with one that
serves the same purpose from views. This is part of cleaning up the
bubble code. Please take a look and provide feedback.

Thanks!

[Robert Sesek, 2015-06-03 16:44:04]

rsesek@chromium.org changed reviewers:
+ tapted@chromium.org

[Robert Sesek, 2015-06-03 16:44:04]

What's the end goal of this refactoring? Is it just to share these constant
values? Why is that useful? My inclination is that Cocoa shouldn't depend on
views.

+trent

[hcarmona, 2015-06-03 18:15:29]

On 2015/06/03 16:44:04, Robert Sesek wrote:
> What's the end goal of this refactoring? Is it just to share these constant
> values? Why is that useful? My inclination is that Cocoa shouldn't depend on
> views.
> 
> +trent

The reason for consolidating these is that both enums do mean the same
thing. This inconsistency is something that I noticed when working on
some bubble issues. Maybe a better approach is to have this enum in a
common location for all bubbles (independent of views and cocoa)?

[tapted, 2015-06-03 21:51:38]

On 2015/06/03 18:15:29, Hector Carmona wrote:
> On 2015/06/03 16:44:04, Robert Sesek wrote:
> > What's the end goal of this refactoring? Is it just to share these constant
> > values? Why is that useful? My inclination is that Cocoa shouldn't depend on
> > views.
> > 
> > +trent
> 
> The reason for consolidating these is that both enums do mean the same
> thing. This inconsistency is something that I noticed when working on
> some bubble issues. Maybe a better approach is to have this enum in a
> common location for all bubbles (independent of views and cocoa)?

Yeah views code shouldn't be getting introduced into existing stuff under
chrome/browser/ui/cocoa. I might need to shuffle things around a bit, but I
should be able to make a DEPS rule to enforce this (probably I just need to move
some bridging classes to chrome/browser/ui/cocoa/views if that doesn't get too
confusing).

A common enum is an option (probably something in ui_base_types), but I seem to
recall arrows being dubbed toolkit-specific.

If it's not high priority, you could imagine a world where
chrome/browser/ui/cocoa disappears entirely... (this is GYP_DEFINES +=
mac_views_browser=1). i.e. if this isn't blocking you, the refactoring might not
be worthwhile.

[hcarmona, 2015-06-03 22:39:59]

On 2015/06/03 21:51:38, tapted wrote:
> On 2015/06/03 18:15:29, Hector Carmona wrote:
> > On 2015/06/03 16:44:04, Robert Sesek wrote:
> > > What's the end goal of this refactoring? Is it just to share these
constant
> > > values? Why is that useful? My inclination is that Cocoa shouldn't depend
on
> > > views.
> > > 
> > > +trent
> > 
> > The reason for consolidating these is that both enums do mean the same
> > thing. This inconsistency is something that I noticed when working on
> > some bubble issues. Maybe a better approach is to have this enum in a
> > common location for all bubbles (independent of views and cocoa)?
> 
> Yeah views code shouldn't be getting introduced into existing stuff under
> chrome/browser/ui/cocoa. I might need to shuffle things around a bit, but I
> should be able to make a DEPS rule to enforce this (probably I just need to
move
> some bridging classes to chrome/browser/ui/cocoa/views if that doesn't get too
> confusing).
> 
> A common enum is an option (probably something in ui_base_types), but I seem
to
> recall arrows being dubbed toolkit-specific.
> 
> If it's not high priority, you could imagine a world where
> chrome/browser/ui/cocoa disappears entirely... (this is GYP_DEFINES +=
> mac_views_browser=1). i.e. if this isn't blocking you, the refactoring might
not
> be worthwhile.

The dupe enum isn't blocking me and it's not high priority, especially
if mac views is right over the horizon.