MacViews: Implement Force Touch/Mac dictionary lookup for Textfields.

ui/views/view.h

Index: ui/views/view.h
diff --git a/ui/views/view.h b/ui/views/view.h
index 55cc02bb54da4eaa205df9f8adc17d5f84245279..a166aa088ab8ae7417904fe55cb9f3e841cb3b55 100644
--- a/ui/views/view.h
+++ b/ui/views/view.h
@@ -573,6 +573,14 @@ class VIEWS_EXPORT View : public ui::LayerDelegate,
   // NULL.
   virtual View* GetTooltipHandlerForPoint(const gfx::Point& point);
 
+  // Retreives the |word| displayed at the given |point|. If no word is
+  // displayed at the |point|, returns a nearby word. |baseline_point| should
+  // correspond to the left baseline point of the leftmost glyph of the |word|
+  // in the view's coordinates. Returns false, if no word can be retreived.
+  virtual bool GetWordAtPoint(const gfx::Point& point,

[tapted, 2016/09/21 04:44:14]

ooh - also I don't think we can justify adding this to the View interface
(particularly if we need another to get this for a selection).

TextInputClient - maybe.

Or it may even be sensible to do some RTTI on Textfield::kViewClassName and a
static cast.

Or it could actually be OK - this is something to check with sky@, but we'll
need a stronger justification. E.g. it's kinda like ToolTips, but currently very
mac specific - did you explore alternatives already? (Or can you think of
alternatives? (possibly bad ones))

[karandeepb, 2016/09/21 05:37:12]

Yeah it seems similar to tooltips but is very Mac specific. So we need to
support 2 usecases -> 

1) For a given point, get the styled word and the baseline point. The point may
not lie inside the focused view.
2) For a given range (selection), get the styled word and the baseline point.
The range will probably always lie within the focused view (We need to think
about how focus behaves with a Label with an active selection.) 

We need to support this for both Labels and Textfields.

Some ideas,
1. Add a GetTextInputClient() method to views::View and add methods
GetWordAtPoint and GetWordForRange to the TextInputClient. But then Labels will
have to implement the TextInputClient interface subsequently (which feels
slightly wrong since Labels never accept input). 

However once Labels start supporting selection, we may need it anyway. More
specifically, what does the interface with Cocoa for use case 2 above look like.
When we right click with an active selection, it shows a LookUp "selected text"
context menu. So it will probably query the BCV for the selected Text and hence
View::Labels might need to inherit from TextInputClient anyway.

2) Subsequently, we'll be adding support for selection to Views::Labels. The
plan is probably to move the selection logic from a Views::Textfield to a
seperate class which can be used by both Textfields and Labels. The new class
will need access to the underlying render text instance and probably have a
virtual GetRenderText method.

How about a new class called RenderTextHostView from which both Labels and
Textfields inherit and which itself inherits from Views::View. 

Then we can add a GetRenderTextHost() method to views::View and methods
GetWordAtPoint and GetWordForRange to the RenderTextHostView. 

But I think the current design is fine for now. We'll have a clearer
understanding of the design needed once we start supporting dictionary popups
and selection for Views::Labels. Thoughts?

[tapted, 2016/09/22 00:50:03]

What about putting a GetRenderText() directly on views::View? That seems like a
nice abstraction - if a View notionally represents some formatted text that's
displayed on screen it can return something, otherwise not. For now we can
assume that (a) there is at most one RenderText per View, and (b) the RenderText
is drawn at the origin of that View's internal coordinate system (or based off
GetInsets()). So the signature could be something like

virtual const gfx::RenderText* View::GetRenderText() { return nullptr; }

Later on we might need to pass in/out a gfx::Point to handle hit tests (e.g.
TableView?), or support views with the RenderText offset (icons?).

[karandeepb, 2016/09/22 08:17:39]

We also need a method which returns non const RenderText since we need to call
non-const methods on it. Ideally the RenderText class should have used mutable
for some member variables. 

+                              gfx::NativeStyledString word,
+                              gfx::Point* baseline_point);
+
   // Return the cursor that should be used for this view or the default cursor.
   // The event location is in the receiver's coordinate system. The caller is
   // responsible for managing the lifetime of the returned object, though that