[WIP] Tool Reorganization Proposal

[aaronayres35]

The changes are an ugly incomplete mess right now in this PR. I would advise not even looking at any code changes made here for the time being. I also do not intend for this PR to ever be merged. The migration process should happen over multiple smaller PRs. I do hope to at some point have made the big picture code changes to get a feel for scope / what the re-org will look like when complete. However, for the time being the useful part of this PR is the added reorg document described below.(EDIT: I went ahead and just reverted the code changes on this PR as they just clouded the current purpose of this PR)

I have added a tool_reorg.rst file sitting in the "Developer Reference" section of the documentation. If you build the docs on this branch that page will outline my investigation so far.

[corranwebster]

So this is likely to be a bit of a brain-dump about how we might go about this.

The first idea is that there should be a model layer which holds a stack of the transformations performed by pan and zoom tools (and related things, I guess), and then there is room to build different interactions on top of that which handle the creation of pan and zoom model objects and then apply them. The reason for the stack of transformations is to allow undo/redo/reset of the pan/zoom, and so having this stack use Pyface undo (or at least be API compatible with it) would be nice.

There is a question about what the model state should be. Currently the tools use the high and low range values I think, but you could also imagine instead storing affine transformation components (ie. a scale factor and origin offset), but in either case there is a problem that things other than the pan and zoom tool can change these (eg. adding more data that increases the range, user resizing the plot, having range tracking turned on, trying to keep image pixels square, etc.) and catching all of these is hard and in some cases its not entirely clear what "undo" should do. As a result, there are lots of subtle UX issues that you can run into if you do the wrong combinations of actions. If we go this route there should be some thought put into how to handle the out-of-band changes to the model state - it would probably involve the zoom/pan transform being one of a set of factors that are fed into the range and mapper computations.

So an alternative is to forget about history and just make the tools dumbly act on the current state of the mappers and ranges and worry about managing undo/redo/reset in a different way later. This is a lot more tractable. You can still build a common core of code for doing the manipulation of ranges and have different tools handle different interactions for manipulating them.

However we go, as much generic stuff as possible should be put down into Enable to handle the nitty gritty of mouse and keyboard interactions - so for example a base tool with only one concrete implementation is fine, if it is designed to be subclassed and exposed via the API for users to derive their own versions.

Anyway, all of that said, I think we want to have tools for panning (and analagous ones for zoom) that operate by:

• mouse movement/dragging (with or without various modifier combinations, and on different mouse buttons)
• key presses (eg. arrow keys or +/- keys, with/without modifiers)
• mouse wheel (with/without modifiers)
• (for zoom) selecting a region in the current plot to be the new viewed area
• (possibly) moving a selection in a different plot
• (stretch goal) using gestures (eg. pinch, swipe)

There may be a nice path for this where there are many small tools that handle a single interaction which can be combined to produce richer results, rather than one monolithic tool that does all of them.

In any case all of those are probably a bit too much to build all at once, but getting a framework where we can easily build out the functionality would be nice.

So not sure if this helps, but it is something to think about.

[aaronayres35]

I'm going to close this PR now, as its contents have been pulled out into stand alone issues