PR #8959 added support for treating keyboard moves as if they were drags in WorkspaceSvg.prototype.isDragging. At present this is done by having a set method, .setKeyboardMoveInProgress, that is called from Mover.prototype.startMove, .finishMove and .abortMove, but there is some possibility that the state of .isKeyboardMoveInProgress could get out of sync with the Mover state.
It would be better to have .isDragging call mover.isMoving(this) directly, to check whether this workspace is one of the keys present in the Mover's .moves map. Unfortunately there is not at present any easy way for a WorkspaceSvg to get access to the (should-but-not-currently-guaranteed-to-be singleton) Mover instance.
It seems likely that Mover will eventually become part of core (and possibly be refactored to be per-Workspace rather than a singleton), at which point this is likely to be much easier.
PR #8959 added support for treating keyboard moves as if they were drags in
WorkspaceSvg.prototype.isDragging. At present this is done by having a set method,.setKeyboardMoveInProgress, that is called fromMover.prototype.startMove,.finishMoveand.abortMove, but there is some possibility that the state of.isKeyboardMoveInProgresscould get out of sync with theMoverstate.It would be better to have
.isDraggingcallmover.isMoving(this)directly, to check whetherthisworkspace is one of the keys present in theMover's.movesmap. Unfortunately there is not at present any easy way for aWorkspaceSvgto get access to the (should-but-not-currently-guaranteed-to-be singleton)Moverinstance.It seems likely that
Moverwill eventually become part of core (and possibly be refactored to be per-Workspace rather than a singleton), at which point this is likely to be much easier.