Bug 266559 - Cannot disable horizontal snapping when AbstractTool is in accessible drag state
Summary: Cannot disable horizontal snapping when AbstractTool is in accessible drag state
Status: NEW
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: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-27 16:02 EST by Marc Baumbach CLA
Modified: 2009-02-27 16:22 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Baumbach CLA 2009-02-27 16:02:45 EST 
Build ID: M20090211-1700

Steps To Reproduce:
1. Select an edit part in a diagram.
2. Enter the accessible drag state.
3. Hold down the appropriate snapping disablement button (ALT on Windows, CTRL on Mac), and attempt to move the edit part horizontally (using either the left or right arrow key).
4. Vertical snapping disablement works fine.


More information:
This appears to be a key binding collision with the navigation actions provided by the Eclipse UI. Alt + (Left|Right) are already registered with the Navigation backward/forward actions.
Comment 1 Randy Hudson CLA 2009-02-27 16:22:52 EST 
Marc, there's a simple workaround possible by the GEF client.  When the state becomes STATE_ACCESSIBLE_DRAG (in your SelectionTool), enable some Context "Foo" that inherits from the eclipse Context "Bar", being the one that defines the ALT+LEFT keybindings, etc.

Then bind those keys to NULL in your "Bar" context. When the accessible states (there are a couple) are finally over, remove the context "Bar" to restore the default behavior.

You should probably create the sub-context programatically to prevent the user from knowing about it.