Community
Participate
Working Groups
Build Identifier: I20100312-1448 Hold down ALT whilst clicking and dragging any figure in a GEF editor - you don't the [+] cursor/indicator that the clone operation is happening. Am runing on Leopard 10.5.8 Cause of the issue is in org.eclipse.gef.tools.DrageEditPartsTracker: /** * Key modifier for cloning. It's ALT on Mac, and CTRL on all other platforms. */ static final int MODIFIER_CLONE; static { if (SWT.getPlatform().equals("carbon")) //$NON-NLS-1$ MODIFIER_CLONE = SWT.ALT; else MODIFIER_CLONE = SWT.CTRL; } Simple fix: the line checking the platform also needs to allow for "cocoa"! (CTRL+click on the Mac actually raises the context menu, as a right mouse click would) There's a few other places that are checking for carbon but still ignoring cocoa. Might be worth raising a separate bug to validate all of these cases? These are the ones I've spotted: - org.eclipse.gef.tools.AbstractTool - org.eclipse.draw2d.text.BidiProcessor - org.eclipse.gef.ui.rulers.RulerComposite Really need this fixed in Helios... am hoping to ship my app on cocoa but can't with this bug. Happy to help out if I can in some way. Reproducible: Always Steps to Reproduce: 1. Open any GEF editor 2. Create a figure 3. press ALT, click the figure and drag 4. figure is simply moved, not cloned
Forgot to mention that the reason why the MODIFIER_CLONE field being wrong affects the ALT drag is in DragEditPartsTracker.setState(): protected void setState(int state) { boolean check = isInState(STATE_INITIAL); super.setState(state); if (isInState(STATE_ACCESSIBLE_DRAG | STATE_DRAG_IN_PROGRESS | STATE_ACCESSIBLE_DRAG_IN_PROGRESS)) { >> if (getCurrentInput().isModKeyDown(MODIFIER_CLONE)) { >> setCloneActive(true); handleDragInProgress(); } } : Mod key is not down (as it's incorrectly expecting CTRL on Cocoa, not ALT) therefore no clone.
We can get this fix into Helios. Can you provide a patch for what you are looking for? Or code snippets for the changes. It would seem the GEF code in question should be changed to: if (Platform.OS_MACOSX.equals(Platform.getOS())) { The draw2d we need to look at closer and add in "cocoa".
Created attachment 167558 [details] Patch for correct Mac OS X detection for correct ALT clone detection Here's the patch with the suggested amendment; works fine for me now.
Committed the patch to HEAD for Helios. (In reply to comment #0) > There's a few other places that are checking for carbon but still ignoring > cocoa. Might be worth raising a separate bug to validate all of these cases? > These are the ones I've spotted: > > - org.eclipse.gef.tools.AbstractTool > - org.eclipse.draw2d.text.BidiProcessor > - org.eclipse.gef.ui.rulers.RulerComposite What about these ones?
I haven't managed to look into the circustances surrounding the other 3 locations yet, as they don't appear to be affecting me as far as I can tell tbh! I can probably take a look at some point - would you like comments here or new entries?
(In reply to comment #5) > I haven't managed to look into the circustances surrounding the other 3 > locations yet, as they don't appear to be affecting me as far as I can tell > tbh! > > I can probably take a look at some point - would you like comments here or new > entries? OK, lets create new Bugzillas for these. This particular issue is solved for Helios.
