ui/touch_selection/selection_event_type.h - Issue 1239583003: Update touch selection notification names, add ESTABLISHED.

Side by Side Diff: ui/touch_selection/selection_event_type.h

Issue 1239583003: Update touch selection notification names, add ESTABLISHED. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Add new SelectionEventTypes for bounds changing instead of reusing an insertion event. Created 5 years, 5 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchSelectionController.java ('K') | « chrome/android/javatests/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchManagerTest.java ('k') | ui/touch_selection/touch_selection_controller.cc » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 // Copyright 2014 The Chromium Authors. All rights reserved.	1 // Copyright 2014 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 #ifndef UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_	5 #ifndef UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_

6 #define UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_	6 #define UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_

7	7

8 namespace ui {	8 namespace ui {

9	9

10 // This file contains a list of events relating to selection and insertion, used	10 // This file contains a list of events relating to selection and insertion, used

11 // for notifying Java when the renderer selection has changed.	11 // for notifying Java when the renderer selection has changed.

12	12

13 // A Java counterpart will be generated for this enum.	13 // A Java counterpart will be generated for this enum.

14 // GENERATED_JAVA_ENUM_PACKAGE: org.chromium.ui.touch_selection	14 // GENERATED_JAVA_ENUM_PACKAGE: org.chromium.ui.touch_selection

15 enum SelectionEventType {	15 enum SelectionEventType {

16 SELECTION_SHOWN,	16 SELECTION_SHOWN,

17 SELECTION_MOVED,	17 SELECTION_MOVED,

18 SELECTION_CLEARED,	18 SELECTION_CLEARED,

19 SELECTION_DRAG_STARTED,	19 SELECTION_DRAG_STARTED,

20 SELECTION_DRAG_STOPPED,	20 SELECTION_DRAG_STOPPED,

21 INSERTION_SHOWN,	21 INSERTION_SHOWN,

22 INSERTION_MOVED,	22 INSERTION_MOVED,

23 INSERTION_TAPPED,	23 INSERTION_TAPPED,

24 INSERTION_CLEARED,	24 INSERTION_CLEARED,

25 INSERTION_DRAG_STARTED,	25 INSERTION_DRAG_STARTED,

26 INSERTION_DRAG_STOPPED,	26 INSERTION_DRAG_STOPPED,

	27 BOUNDS_ESTABLISHED,
	jdduke (slow) 2015/07/15 23:08:51 mohsen@: Any preference on naming here? We'd like mohsen@: Any preference on naming here? We'd like to distinguish between user selections and general selections (e.g., JS selections or contextual search selections). I can't say I love BOUND_ESTABLISHED/DISSOLVED, maybe EMPTY_SELECTION/NON_EMPTY_SELECTION? If you'd prefer such notifications happen outside the TouchSelectionController, I'd be OK with that as well. jdduke (slow) 2015/07/15 23:13:38 Hmm, or we could change the existing types, adding Show quoted text On 2015/07/15 23:08:51, jdduke wrote: > mohsen@: Any preference on naming here? We'd like to distinguish between user > selections and general selections (e.g., JS selections or contextual search > selections). I can't say I love BOUND_ESTABLISHED/DISSOLVED, maybe > > EMPTY_SELECTION/NON_EMPTY_SELECTION? > > If you'd prefer such notifications happen outside the TouchSelectionController, > I'd be OK with that as well. Hmm, or we could change the existing types, adding a _HANDLE_ in the middle, e.g. SELECTION_HANDLES_SHOWN, INSERTION_HANDLE_SHOWN, and then we could just have a general SELECTION_ACTIVATED/DEACTIVATED. mohsen 2015/07/16 18:02:49 The only issue I have with this suggestion is use Show quoted text On 2015/07/15 23:13:38, jdduke wrote: > On 2015/07/15 23:08:51, jdduke wrote: > > mohsen@: Any preference on naming here? We'd like to distinguish between > user > > selections and general selections (e.g., JS selections or contextual search > > selections). I can't say I love BOUND_ESTABLISHED/DISSOLVED, maybe > > > > EMPTY_SELECTION/NON_EMPTY_SELECTION? > > > > If you'd prefer such notifications happen outside the > TouchSelectionController, > > I'd be OK with that as well. > > Hmm, or we could change the existing types, adding a _HANDLE_ in the middle, > e.g. SELECTION_HANDLES_SHOWN, INSERTION_HANDLE_SHOWN, and then we could just > have a general SELECTION_ACTIVATED/DEACTIVATED. The only issue I have with this suggestion is use of activate/deactivated. We have used these terms for when handles are shown/hidden, i.e. when "touch selection" is activated/deactivate; while here we are not necessarily showing handles, IIUC. Maybe, something like SELECTION_ESTABLISHED/_DISSOLVED (or _DISMISSED) would be better. Otherwise, the changes look good to me.
	28 BOUNDS_DISSOLVED

27 };	29 };

28	30

29 } // namespace ui	31 } // namespace ui

30	32

31 #endif // UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_	33 #endif // UI_TOUCH_SELECTION_SELECTION_EVENT_TYPE_

OLD	NEW