Bugzilla – Full Text Bug Listing
| Summary: | [mac] drag-n-drop of a task to a category doesn't work | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | maarten meijer <mjmeijer> | ||||||||||
| Component: | Mylyn | Assignee: | Leo Dos Santos <leo.dos.santos> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | leo.dos.santos, mik.kersten, steffen.pingel | ||||||||||
| Version: | dev | ||||||||||||
| Target Milestone: | 2.2 | ||||||||||||
| Hardware: | Macintosh | ||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
maarten meijer
Leo: can you reproduce this? Also see: https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=DND&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&rep_platform=Macintosh&op_sys=Mac+OS+X&bugidtype=include&cmdtype=doit Something's wromng with Mac DnD, but workarounds seem to exist. (In reply to comment #1) > Leo: can you reproduce this? Indeed I can. I don't use categories, but I don't think I can remember this ever working. Please note that in the SWT Example Launcher, and dragging from anything (on the Drag Source) to a list (on Drop Target), it only works when the DND.DRAG_MOVE is enabled on the Drag Source side :-( Maarten, Leo: are you dropping onto a task, or between tasks? Dropping onto a task is not currently supported because we reserved it for creating subtasks. Maybe we should revisit that decision. No, I tried dropping it onto the container title. It doesn't matter, dragging onto container title, task, or between tasks results in the same error. I don't know about Maarten, but I always get an Unhandled event loop exception: java.lang.NullPointerException at org.eclipse.swt.dnd.DragSource.dragSendDataProc(DragSource.java:389) at org.eclipse.swt.dnd.DragSource.DragSendDataProc(DragSource.java:195) at org.eclipse.swt.internal.carbon.OS.TrackDrag(Native Method) at org.eclipse.swt.dnd.DragSource.drag(DragSource.java:347) at org.eclipse.swt.dnd.DragSource$1.handleEvent(DragSource.java:163) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1495) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1519) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1504) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1295) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3350) at org.eclipse.swt.widgets.Control.sendTrackEvents(Control.java:2831) at org.eclipse.swt.widgets.Control.kEventControlTrack(Control.java:1953) at org.eclipse.swt.widgets.Widget.controlProc(Widget.java:367) at org.eclipse.swt.widgets.Display.controlProc(Display.java:835) at org.eclipse.swt.internal.carbon.OS.CallNextEventHandler(Native Method) at org.eclipse.swt.widgets.Tree.kEventMouseDown(Tree.java:2363) at org.eclipse.swt.widgets.Widget.mouseProc(Widget.java:1262) at org.eclipse.swt.widgets.Display.mouseProc(Display.java:2819) at org.eclipse.swt.internal.carbon.OS.SendEventToEventTarget(Native Method) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2938) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2219) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:461) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:169) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:363) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:508) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:447) at org.eclipse.equinox.launcher.Main.run(Main.java:1173) at org.eclipse.equinox.launcher.Main.main(Main.java:1148) I can't reproduce the exception on my test workspace, although dnd does not work their either. (In reply to comment #5) > Maarten, Leo: are you dropping onto a task, or between tasks? I drop on the category title and get the same unhandled event loop exception... Leo, did you find out more about the cause of the problem? The only hint I've found is that the drag listeners seem to fire off a lot earlier on the Mac than on Windows, but I haven't looked at this since Tuesday. Will try to get this resolved before the weekend is up, if you want to reassign to me. What I noticed in Task List drop adapter is that it is using current selection to figure out the drop target. The selection is probably correct when drag feedback is enabled, but it still doesn't seem right. If I am not mistaken, think Mik wrote that code, maybe he can comment on that. I would think that drop target should be based on the tree item under the current cursor location (similar to how tooltips work). (In reply to comment #11) > What I noticed in Task List drop adapter is that it is using current selection > to figure out the drop target. Sounds like the Baron of Munchhausen pulling himself from the marsh by his bootstraps... That's great Leo, assigning to you. As far as I understand the code the current selection is used to determine which object is being dragged. It is used to prevent queries of being dragged but it does not work on Mac since the item is unselected on Mac OS X when a drag starts. Leo, you could investigate replacing TaskTransfer by LocalSelectionTransfer which stores the selection in the transfer object instead of getting the selection from the viewer. Another option is to fix TaskTransfer which is expects an array of AbstractTask objects but gets passed an array of Objects in javaToNative() so it never serializes the dragged objects correctly. Either way, this will require some cleanup of TaskListDropAdapter to not access the selection of the tree but to use the transfer objects instead. Created attachment 84110 [details]
fix serializing tasks in TaskTransfer
Leo, it would be great if you could take a look at the patch and report back if that works on Mac OS X.
Created attachment 84111 [details]
mylyn/context/zip
Unfortunately this patch doesn't fix the issue on Mac. Okay, we can take another look at the problem together tomorrow. I have committed a modified version of the patch to get rid of the dependency on the tree selection but we may have to use LocalSelectionTransfer to get it working on Mac OS X. Created attachment 84223 [details]
refactoring of TaskListDragSourceListener
Steffen, can you apply this and confirm that it doesn't break on non-Mac systems?
Created attachment 84224 [details]
mylyn/context/zip
Great work Leo! Works perfectly on Linux. I have applied your patch with additional refactorings in TaskListSourceListener to simplify the code even more. Leo, please verify on Mac OS X and close this report if it works. Yes it works. Thanks for the help Steffen. Are you guys sure that saving current selection in the drag source listener and not cleaning it is harmless? |