Reorganize Tools
Related to #438 Pulling the contents of #739 into an issue:
This is the current starte of Pan and Zoom tools accross Chaco and Enable (red = in enable):
However, seems to have been intended as improvement over PanTool.> ]; DragTool -> PanTool2; } ```

Until recently, there had also been a BaseZoomTool and SimpleZoom living in chaco. These now exist in enable (with some trimming / modifications) and are the BaseZoomTool and ViewportZoomTool above. Additionally, we recently removed the duplicate of the enable DragTool which was living in chaco.
RectZoom and TrackingZoom are intended as convenience classes but end up clouding the api. Instead we should simply have a ZoomTool class (which is actually BetterSelectingZoom, but that code can be copied over and BetterSelectingZoom removed). This is the "default" / go-to zoom tool most users will use. If they want the current RectZoom or TrackingZoom functionality, there should simply be an easy way to configure a ZoomTool to do so. Either by setting a trait like rect=True or tracking=True, or perhaps with some class method on ZoomTool. This way it will be more obvious what tool you want if you want zoom functionality (you want the ZoomTool!) and it can be confiugred to your needs. Similar logic applies to TrackingPanTool and either PanTool. Although currently, TrackingPanTool subclasses PanTool1.
The current BetterZoom class can be renamed as BaseZoomTool. The way things currently are (with ZoomTool an alias for BetterSelectingZoom), the "default" zoom tool has selecting functionality. There are situations like DragZoom where you don't want this. AFAICT, users are not expected to use BetterZoom directly. As such, it makes sense to make it an explicit base class.
In enable, I do not really see why BaseZoomTool needs to be its own class. It is only used by ViewportZoomTool, and is not exposed in any api module. Further, from what I can tell, enable zoom functionality is only possible via a Canvas with a Viewport. So only having a ViewportZoomTool seems reasonable. However, if the class is anticipated to be used as a base class for other zoom tool variants, BaseZoomTool can easily stay.
Additionally, either pan_tool.PanTool or pan_tool2.Pantool should be removed. (I still need to investigate the feature disparity / advantages of one over the other, if any exist)
After some initial investigation it is clear much of the code is copy pasted. However, some obvious differences include:
- PanTool1 subclasses
BaseToolwhereas PanTool2 subclassesDragTool - PanTool1 has
pan_{right/left/up/down}_keytraits, PanTool2 does not - PanTool1 also allows "middle" for
drag_button, PanTool2 (inheritingdrag_buttonfrom enableDragTool) only allows "left" or "right" - PanTool1 sets event state to "panning" and defines "panning" specific methods whereas PanTool2 overrides methods on DragTool (e.g.
dragging,drag_cancel,drag_end)
Potentially relevant issues include enthought/chaco#519, and enthought/enable#90.
The following is a proposal for a new class heirarchy:
However, seems to have been intended as improvement over PanTool.>, style="dotted" ]; DragTool -> PanTool2; } ```

Migration Steps:
- Rename
BetterZoomasBaseZoomTool - Copy
BetterSelectingZoomintoZoomTooland delete oldBetterSelectingZoom, or delete oldZoomTooland renameBetterSelectingZoomasZoomTool - Decide on means for replacing
RectZoomandTrackingZoomand with functionality onZoomTool-
RectZoomcurrently just subclassesZoomTool(akaBetterSelectingZoom) and setstool_mode = "box"/always_on = True -
TrackingZoomcurrently just subclassesZoomTool(akaBetterSelectingZoom) and defines anormal_mouse_wheelmethod.
-
- Do the same for
TrackingPanTool(which just subclassesPanTooland overrides_end_pan). - Chose one of
pan_tool.PanToolandpan_tool2.PanToolto be the go-to PanTool moving forawd. Update as needed / Delete the other. - Decide fate of
BaseZoomToolin enable.