Bugzilla – Full Text Bug Listing
| Summary: | [cocoa, gef] Cannot clone figure when running on Cocoa | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Justin Dolezy <justin> | ||||
| Component: | GEF-Legacy GEF (MVC) | Assignee: | Anthony Hunter <ahunter.eclipse> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | ahunter.eclipse | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 3.6.0 (Helios) RC1 | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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. |
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