You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
```
digraph OldToolInheritanceTree {
BetterZoom -> DragZoom;
BetterZoom -> BetterSelectingZoom;
ZoomTool [
label=Currently just an alias for BetterSelectingZoom>
];
BetterSelectingZoom -> ZoomTool [dir=none];
RectZoom [
label=Just sets 2 traits on ZoomTool>
];
ZoomTool -> RectZoom;
TrackingZoom [
label=Defines one additional method on ZoomTool>
];
ZoomTool -> TrackingZoom;
DragTool [fillcolor=red, style=filled];
DragTool -> DragZoom;
BaseZoomTool [fillcolor=red, style=filled];
ViewportZoomTool [fillcolor=red, style=filled];
ViewportPanTool [fillcolor=red, style=filled];
DragTool -> ViewportPanTool;
BaseZoomTool -> ViewportZoomTool;
PanTool;
TrackingPanTool [
label=Defines one additional method on PanTool>
];
PanTool -> TrackingPanTool;
PanTool2 [
label=Not in chaco.tools.api, very rarely used. 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 has pan_{right/left/up/down}_key traits, PanTool2 does not
PanTool1 also allows "middle" for drag_button, PanTool2 (inheriting drag_button from enable DragTool) 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)
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
andSimpleZoom
living in chaco. These now exist in enable (with some trimming / modifications) and are theBaseZoomTool
andViewportZoomTool
above. Additionally, we recently removed the duplicate of the enableDragTool
which was living in chaco.RectZoom
andTrackingZoom
are intended as convenience classes but end up clouding the api. Instead we should simply have aZoomTool
class (which is actuallyBetterSelectingZoom
, but that code can be copied over andBetterSelectingZoom
removed). This is the "default" / go-to zoom tool most users will use. If they want the currentRectZoom
orTrackingZoom
functionality, there should simply be an easy way to configure aZoomTool
to do so. Either by setting a trait likerect=True
ortracking=True
, or perhaps with some class method onZoomTool
. This way it will be more obvious what tool you want if you want zoom functionality (you want theZoomTool
!) and it can be confiugred to your needs. Similar logic applies toTrackingPanTool
and eitherPanTool
. Although currently,TrackingPanTool
subclassesPanTool1
.The current
BetterZoom
class can be renamed asBaseZoomTool
. The way things currently are (withZoomTool
an alias forBetterSelectingZoom
), the "default" zoom tool has selecting functionality. There are situations likeDragZoom
where you don't want this. AFAICT, users are not expected to useBetterZoom
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 byViewportZoomTool
, and is not exposed in any api module. Further, from what I can tell, enable zoom functionality is only possible via aCanvas
with aViewport
. So only having aViewportZoomTool
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
orpan_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:
BaseTool
whereas PanTool2 subclassesDragTool
pan_{right/left/up/down}_key
traits, PanTool2 does notdrag_button
, PanTool2 (inheritingdrag_button
from enableDragTool
) only allows "left" or "right"dragging
,drag_cancel
,drag_end
)Potentially relevant issues include #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:
BetterZoom
asBaseZoomTool
BetterSelectingZoom
intoZoomTool
and delete oldBetterSelectingZoom
, or delete oldZoomTool
and renameBetterSelectingZoom
asZoomTool
RectZoom
andTrackingZoom
and with functionality onZoomTool
RectZoom
currently just subclassesZoomTool
(akaBetterSelectingZoom
) and setstool_mode = "box"
/always_on = True
TrackingZoom
currently just subclassesZoomTool
(akaBetterSelectingZoom
) and defines anormal_mouse_wheel
method.TrackingPanTool
(which just subclassesPanTool
and overrides_end_pan
).pan_tool.PanTool
andpan_tool2.PanTool
to be the go-to PanTool moving forawd. Update as needed / Delete the other.BaseZoomTool
in enable.The text was updated successfully, but these errors were encountered: