Update during transform

[focomoso]

Currently the actionListener is only called on pointer up. It would be very helpful to have it get called while the user was actively manipulating the control (so we can show the user how much they've moved/rotated/scaled the object, for example). It's important that the API distinguish between the two types of actions.

I can see three ways to handle this.

1. Add an "updateOnMove" flag - when set, the control calls the action listener on every move
2. Add a new type of listener - to distinguish from the current action
3. Add new action types - eg: ActionType.TRANS_MOVE, .ROT_MOVE, SCALE_MOVE

My vote would be option 3 because it clearly distinguishes between the types of action and doesn't add the confusion of different types of listeners. We could also think of adding a ActionType.TRANS_START, .ROT_START and .SCALE_START incase people want to do something else while the user is manipulating the control (like open up a 'stats' window).

Once we decide on an option, I'm happy to add this myself (once I figure out the compiling issue).

Thanks,

James

[ssatguru]

I did think about this before but was a bit worried about performance - doing a callback during manipulation would results in hundreds of calls. maybe two callbacks to indicate start and end ?

[focomoso]

I don't think it'll be a problem. Most of the time the callback won't even be registered and if it is, a simple test of the ActionType shouldn't make a noticeable difference.

[focomoso]

Pull request created. There was no noticeable difference calling the move actions (as long as you don't print to the console every time - in that case, you can see a little lag, but that's just the crappy console).

[ssatguru]

Thanks for working on this and the pull request
Decided on a slightly different approach though.
Instead of adding new action types I have added new action listeners
So now we have three action listeners , ActionStartListener, ActionListener, ActionEndListener.
See Readme for details
Two reasons

1. actionTypes was initially and primarily added for history - undos and redos. start and end actions do not make sense for history
2. if the user is only interested in start or end then he does not incur the overhead of multiple call backs during an action