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

ui/views/view.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_VIEWS_VIEW_H_
 #define UI_VIEWS_VIEW_H_
 
 #include <stddef.h>
 
 #include <algorithm>
@@ skipping 555 matching lines @@
   // Returns the View that should be the target of an event having |rect| as
   // its location, or NULL if no such target exists. |rect| is in the local
   // coordinate space of |this|.
   View* GetEventHandlerForRect(const gfx::Rect& rect);
 
   // Returns the deepest visible descendant that contains the specified point
   // and supports tooltips. If the view does not contain the point, returns
   // 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
   // lifetime may vary from platform to platform. On Windows and Aura,
   // the cursor is a shared resource.
   virtual gfx::NativeCursor GetCursor(const ui::MouseEvent& event);
 
   // A convenience function which calls HitTestRect() with a rect of size
   // 1x1 and an origin of |point|. |point| is in the local coordinate space
   // of |this|.
@@ skipping 978 matching lines @@
   // Belongs to this view, but it's reference-counted on some platforms
   // so we can't use a scoped_ptr. It's dereferenced in the destructor.
   NativeViewAccessibility* native_view_accessibility_;
 
   DISALLOW_COPY_AND_ASSIGN(View);
 };
 
 }  // namespace views
 
 #endif  // UI_VIEWS_VIEW_H_