Bug 213359 - Make GEF's snapping and tools extensible to allow moving shapes with arrow keys
Summary: Make GEF's snapping and tools extensible to allow moving shapes with arrow keys
Status: RESOLVED FIXED
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy GEF (MVC) (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4.0 (Ganymede) M5   Edit
Assignee: Cherie Revells CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks: 111901
  Show dependency tree
 
Reported: 2007-12-18 15:04 EST by Cherie Revells CLA
Modified: 2008-09-18 13:33 EDT (History)
1 user (show)

See Also:


Attachments
patch (11.90 KB, patch)
2007-12-18 15:04 EST, Cherie Revells CLA
no flags Details | Diff
updated patch (13.71 KB, patch)
2007-12-19 12:10 EST, Cherie Revells CLA
ahunter.eclipse: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Cherie Revells CLA 2007-12-18 15:04:14 EST
Created attachment 85486 [details]
patch

I am changing the behavior of GEF in GMF so that the user can press an arrow key on a shape and this will move the shape.  In order to do this, I would like to make a few changes in GEF, so that it is possible to extend GEF in this manner.

I am attaching a patch that does the following:
- Add getter for THRESHOLD in SnapToGuides so it can be overridden.  This was already done in SnapToGeometry.
- Make CompoundSnapToHelper.getDelegates() protected so subclasses can access the delegates.
- Make TargetingTool.resetHover() protected so it can be called by subclasses to change the behavior of the SelectionTool.
- Make GraphicalViewerKeyHandler.getNavigationSiblings() and isViewerMirrored() protected as they are useful for subclasses.
- Extracted the snapping behavior into a new method snapPoint(request) in DragEditPartsTracker so that clients can customize the snapping behavior (I want to add extended data to the request to restrict the direction of snapping).

Alex has code reviewed.  Anthony, can you look at these changes and commit?
Comment 1 Cherie Revells CLA 2007-12-19 12:10:09 EST
Created attachment 85579 [details]
updated patch

I've attached a patch that includes changes to AbstractTool.  Specifically:
AbstractTool.Input.setMouseLocation() changed to public.
AbstractTool.placeMouseInViewer() changed to protected.
AbstractTool.acceptArrowKey() changed to protected.

History of why I need these changes (if interested)...
If I press the arrow key while the mouse is outside the diagram viewer, the new location of the shape is off.  The reason is as follows:
- DragEditPartsTracker.handleKeyDown() is called when the arrow key is pressed.
- This sets the start location based on the current mouse location (which is outside the viewer).
- Then placeMouseInViewer(getLocation().getTranslated(0, accGetStep())) is called which not only moves the mouse by the translated amount, but also moves the mouse into the viewer (although the location in the current input is not updated)
- Later when getDragMoveDelta() is called to update the move delta in the request, the start location and current mouse location differ significantly affecting the move.

I have fixed this in GMF, by first moving the cursor to the center of the shape when an arrow key is pressed:
    protected boolean handleKeyDown(KeyEvent e) {
        if (acceptArrowKey(e)) {
            if (isInState(STATE_INITIAL)) {
                IGraphicalEditPart ep = (IGraphicalEditPart) getSourceEditPart();
                if (ep != null) {
                    Point location = ep.getFigure().getBounds().getCenter();
                    ep.getFigure().translateToAbsolute(location);
                    placeMouseInViewer(location);       
                    getCurrentInput().setMouseLocation(location.x, location.y);
                }
            }
        }
        return super.handleKeyDown(e);
    }
Comment 2 Anthony Hunter CLA 2007-12-21 14:29:30 EST
Committed to HEAD