Community
Participate
Working Groups
Use case: When I want to gather various tasks under one heading I create a Category in the task list. I can fill that only by dragging a task from other parts of the task list and dropping it on the category. When I have a task open in the rich task editor, I want a 'handle' to drag it into the category. Reference from somewhere else: In BBEdit on Mac OSX you can drag the icon in the document title bar any place you can drag an alias.
+1. This can be implemented via the new support in Eclipse 3.3 forms, see the "Drag and Drop Support" section of: http://www.eclipse.org/articles/article.php?file=Article-Forms33/index.html This is a nice isolated contribution, so tagging as bugday.
(In reply to comment #1) > +1. This can be implemented via the new support in Eclipse 3.3 forms, see the > "Drag and Drop Support" section of: > > http://www.eclipse.org/articles/article.php?file=Article-Forms33/index.html > > This is a nice isolated contribution, so tagging as bugday. OK, so it seems easy, but now I find that dragging a task from a query to a category doesn't put that into that category doesn't work at all on a Mac! Opening new bug 211080: Drag-n-Drop of a task to a Category doesn't work on a Mac https://bugs.eclipse.org/bugs/show_bug.cgi?id=211080
Maarten, are you interested in working on this?
In fact I have already started... But I'm held back by bug 211080 so I'll have to work on my other machine :-(
Created attachment 83911 [details] making header editable Make header draggable is trivial, but it seems like there are issues in TaskListDropAdapter, so it is rather tricky to make it accept some tranfer object that would represent repository task not from the task list (i.e. for tasks opened from search view or using "open repository task" dialog. Anyways, whoever interested working on this, here is my task context and patch enabling dragging from the task editor header. It also fixes dropping to the task header.
Created attachment 83912 [details] mylyn/context/zip
Created attachment 83913 [details] support for repository tasks Now this is something usable. Used text transfer with task url. Now works with tasks from task list and repository tasks. Also works for dragging task list tasks to external folders using file transfer, but since there is no task instance this is not supported for repository tasks (perhaps will need to create dummy task instance in order to create export file in this case, something like task list drop adapter does wehn creating task from ur).
Mik, assigning to you for review.
Eugene beat me to it... However I was thinking that this code needs to go in TaskEditor, as the dragging handle is then available from all tabs for local tasks and repository tasks, also from the schedule tab of a browser only connector. Secondly I would think that we also need to handle the TaskTransfer Dragging the handle onto another task would create/set make that a subtask. Now if I could only drag that task onto my calendar and have it appear on the scheduled day...
Maarten, you are right about TaskEditor. I've had TaskTransfer, but it didn't work very well for dragging things from outside of Task List back into the task list and it seem like TaskListDropAdapter will need to be refactored to handle it better. Dragging things into task editor is a good idea, but I think it should be covered by a separate bug report and I'd use specific drop targets on "depends on" and "blocks" fields.
Created attachment 84047 [details] Similar mods, but in TaskEditor Only exporting FileTransfer and TextTransfer representation but code is there fro when TaskTransfer can be received. I hope DnD will be fixed on tha Mac
Created attachment 84048 [details] mylyn/context/zip
(In reply to comment #11) > Created an attachment (id=84047) > Similar mods, but in TaskEditor Maarten, unlike with my version, the following scenarios does not work with this patch: -- for task that is already in some query in the task list, dragging editor handle to category bring up dialog "task already exists. do you want to override its context" -- for task that is not in the task list (i.e. opened from search results or from "Open repository task" dialog), dragging editor handle to the taks list generates a error to the log "Data does not have correct format for type", same error happens for dragging this task to outside of workbench (i.e. to some folder on the file system (it should create exported ), but also need to try dragging to IM app to support sending context files)
I'll wait for the fixing of bug 211080 before continuing as that will refactor soem of the drag code.
Eugene, I moved your code to TaskEditor: - I can now drag the handle from the TaskEditor to a category (its just the URL as text) and it appears correctly - I can drag the handle to the finder and it becomes a URL alias, clicking open the browser (so not a file here) but that is because text is tested first ;-) - can't drag this URL back into the task list, but I can double click it and drag the URL from the browser to the tasklist.
Created attachment 84201 [details] mylyn/context/zip
Not sure what in bug 211080 will resolve any needs for issue. That bug is considered specific to Mac OS X. BTW, there is another scenario to test - dragging bot tasklist and non-tasklist tasks to the text field, in entry in the web browser (text drag-n-drop). Try to do that from Task List view, so task editor should work similarly. Can you drag it to a folder or mail app? It should create a ZIP archive and NOT the url link. Try the same from the task list.
when TaskEditor.createHeaderContents() is called the rest isn't initialized yet, so only TExt is generated :-( I think your apporaioch is therefor better, so siblings of AbstractRepositoryTaskEditor shoukld implement their own drag & drop handle.
(In reply to comment #18) > siblings of AbstractRepositoryTaskEditor should implement their own drag & drop handle. maybe dnd initialization can be moved some other place, so it will get initialized at the time when task is set to the editor
I offer two flavors from the Title handle: TextTransfer and FileTransfer I think that updateFormTitle() twice uses a local variable that shadows the task field. So that should be fixed before proceeding. /* AbstractTask */task = ((TaskEditorInput) input).getTask(); /* AbstractTask */task = ((RepositoryTaskEditorInput) input).getRepositoryTask(); Then one can install title drag with a non-null task: I can drag a local task from the handle all tabs to the desktop, a file is created, so OK. I can drag a repository task from the handle all tabs to the desktop, a file is created, so OK. I can drag a repository task from the handle all tabs to a category, but then it is moved, not copied because TaskListDropAdapter is treating a URL always as a MOVE since it doesn't check the operation kind. What would be the proper nrmal behavior here: MOVE or COPY. Personally I think a task should be COPIED into the category when dragged from the handle. I can drag a local task from the handle all tabs to a category, but then an Unhandled Event loop exception error is generated in the log with: org.eclipse.swt.SWTException: Data does not have correct format for type at org.eclipse.swt.dnd.DND.error(DND.java:257) at org.eclipse.swt.dnd.DND.error(DND.java:208) at org.eclipse.swt.dnd.TextTransfer.javaToNative(TextTransfer.java:61) at org.eclipse.swt.dnd.DragSource.dragSendDataProc(DragSource.java:385) 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:2815) at org.eclipse.swt.widgets.Control.actionProc(Control.java:115) at org.eclipse.swt.widgets.Display.actionProc(Display.java:355) at org.eclipse.swt.internal.carbon.OS.CallNextEventHandler(Native Method) at org.eclipse.swt.widgets.Widget.kEventControlTrack(Widget.java:1062) at org.eclipse.swt.widgets.Control.kEventControlTrack(Control.java:1950) 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.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) Should I proceed and modify TaskListDropAdapter to listen to COPY or MOVE?
Created attachment 84309 [details] DnD title handle that can be dragged - Works when dragging to desktop - MOVE instead of COPY when dragging repository task - error when dragging local task
Created attachment 84310 [details] mylyn/context/zip
Steffen: please reivew.
Maarten, thanks for the patch and for pointing out the bugs related to ignoring the operation type. I would like to do a review of the current state of the drag and drop support for version 2.3 to get a better sense what the current implementation actually does and what it is expected to do (e.g. I would expect that the bug id is pasted when a task is dragged to a text field and shift is pressed vs. pasting the complete details). I'll take a look at your patch as part of that review.
Created attachment 84939 [details] UI dragsopurces and droptargets I think there are the following dragsources: a repository task in tasklist b local task in task list c local task drag title d repository task drag title e task file on the desktop, alt. URL on desktop There are also the following drop targets: A a category in the tasklist B the depends on field, resultimng in a dependency C the block field, resulting in a dependency D the attachment title, only for files from the desktop E either pure text past or a reference to another task is inserted F the desktop, resulting in an exoport of a task file THere are probably more candidates.
(In reply to comment #25) > THere are probably more candidates. Few more that haven't included into that list: - dragging url from the web browser into task list creates repository task (if repository can be detected from task url) or local task linked with the corresponding web page (if repository can't be detected from that url) - dragging query export file from local folder or link to query archive from the web browser should import that query into the task list. See bug 204841 - dragging query URL should create query (if query url can be recognized). I am not sure if there is a bug for that
I'll take a look at this in the next few weeks.
Sorry, I meant to say next few _days_ ;).
I reviewed the patch but I am concerned that a large part of the code overlaps with TaskListDragSourceListener. I would prefer to refactor the drag and drop support into a reusable class that works based on ISelection similar to SelectionTransferDragAdapter that can be shared by the task list and editor.
(In reply to comment #29) > I reviewed the patch but I am concerned that a large part of the code overlaps > with TaskListDragSourceListener. I would prefer to refactor the drag and drop > support into a reusable class that works based on ISelection similar to > SelectionTransferDragAdapter that can be shared by the task list and editor. > In view of comment 25 and 26: Given the number of drag sources and drop targets a separate class to handle all seems right. Can I assist in any way? I think the Task list drop reception code needs to be reviewed and generalized first.
I made a first pass at documenting the dnd support (the italic items denote planned enhancements): http://wiki.eclipse.org/Mylyn/UI_Design#Task_Drag_.26_Drop You are very welcome to contribute a more generic class for handling. I think it is best to keep the dragging and dropping code separate. A good start would be to refactor the drag source code to be shared between the task list and editor. Could you provide more details about what you have in mind for generalizing the drop adapter? Part of that code depends on the task list import/export facilities that Rob and I looked over today. Our conclusion was that these need to be reworked first and can then be reused by the dnd code which should make TaskListDropAdapter significantly simpler. I'll comment on bug 209327 with more details. I'll lower the priority of this bug for now. I would like to add this for 2.3 but let's try to refactor the code first. In case the refactoring is not completed in time we can still consider the original patch.
I got this exception while running with the patch and trying to refresh incoming changes: org.eclipse.swt.SWTException: Failed to execute runnable (org.eclipse.swt.SWTError: Cannot initialize Drag) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:126) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3296) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2974) 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:597) 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) Caused by: org.eclipse.swt.SWTError: Cannot initialize Drag at org.eclipse.swt.dnd.DND.error(DND.java:242) at org.eclipse.swt.dnd.DND.error(DND.java:208) at org.eclipse.swt.dnd.DragSource.<init>(DragSource.java:160) at org.eclipse.ui.internal.forms.widgets.TitleRegion.addDragSupport(TitleRegion.java:501) at org.eclipse.ui.internal.forms.widgets.TitleRegion.addDragSupport(TitleRegion.java:491) at org.eclipse.ui.internal.forms.widgets.FormHeading.addDragSupport(FormHeading.java:1042) at org.eclipse.ui.forms.widgets.Form.addTitleDragSupport(Form.java:728) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.installTitleDrag(TaskEditor.java:421) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.updateFormTitle(TaskEditor.java:492) at org.eclipse.mylyn.tasks.ui.editors.TaskEditor.updateTitle(TaskEditor.java:372) at org.eclipse.mylyn.tasks.ui.editors.AbstractRepositoryTaskEditor.updateEditorTitle(AbstractRepositoryTaskEditor.java:2692) at org.eclipse.mylyn.tasks.ui.editors.AbstractRepositoryTaskEditor$46.run(AbstractRepositoryTaskEditor.java:3506) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) ... 23 more
(In reply to comment #32) > I got this exception while running with the patch and trying to refresh incoming > changes: > > org.eclipse.swt.SWTException: Failed to execute runnable True, but only for Local Tasks. Dragging bugzilla tasks to a categhory works for example. So question is: make LocaTask more like RepositoryTask or special case or ignore LocalTask for dragging.
Replacing in the anonymous DragSourceAdapter the line: event.data = task.getUrl(); // goes wrong with LocalTask with: event.data = CopyTaskDetailsAction.getTextForTask(task); resolves the exception. All types of tasks can be dragged by their handles. Only the tasks are duplicated and stay in the Uncategorized :-( This is something in the TaskListDropAdapter, which doesn't check the operation type of the drag. See comment 20/24 and should always remove from Uncategorized... For this functionality I propose that a normal drag gives a DROP_MOVE and the shift key pressed gives a DROP_COPY to the category. THe DROP_MOVE should remove its original parent/remove it from its orginal parent, the DROP_COPY should just add the new parent/add to its new parent. Maybe use some API provided by resolution of bug 210801
Created attachment 88136 [details] new patch resolving problem with localtasks
The stack trace posted in comment #32 was caused by an incoming change while the editor was opened. I clicked the link in the editor title which invokes AbstractRepositoryTaskEditor.refreshEditor(). Maybe the drag source adapter can't be registered more than once?
(In reply to comment #36) > Maybe the drag source adapter can't be registered more than once? True, changed the code and got it to work, please reassign to me, I will upload patch tomorrow after testing some more and adding javadoc.
That's great. I'll apply the new patch to my workspace and test it. If it works correctly for local tasks and repository tasks we might be able to merge it for 2.3.
Created attachment 88394 [details] allowing title drag without ErroLog entries
Created attachment 88395 [details] mylyn/context/zip
Created attachment 88426 [details] cleaner code refactoring left an unused parameter...
Comment on attachment 88394 [details] allowing title drag without ErroLog entries Contains unused variable
Created attachment 88962 [details] updated patch Maarten, please take a look at the updated patch. It's based on your work but generalizes TaskListDragSourceListener instead of duplicating the code. Are there any outstanding todos for the patch that need to be addressed?
Created attachment 88963 [details] mylyn/context/zip
When you drag a Form Title it is always just one task that is involved. I copied code and changed sequence of handling because I thought it wasteful to create the list, add to it and then convert to an array... But having the same general case is to be preferred, so OK. I don't like the following in TaskEditor#updateFormTitle AbstractTask task = null; // is shielding a protected field in the same class The field is already retrieved and initialized and thus this is unnecessary as a local variable. So why not remove this...
(In reply to comment #45) > When you drag a Form Title it is always just one task that is involved. > I copied code and changed sequence of handling because I thought it wasteful to > create the list, add to it and then convert to an array... The cost of that is very small compared to the burden of maintaining duplicated code ;). > I don't like the following in TaskEditor#updateFormTitle > AbstractTask task = null; // is shielding a protected field in the same class > The field is already retrieved and initialized and thus this is unnecessary as a > local variable. Yes, that is not very pretty. It is just a conservative measure that preserves the semantics of the old code to not introduce any unforseen side effects. Hopefully we'll get a chance to clean up the code for 3.0 and properly initialize the task field in one place.
I have committed the patch to CVS. A new weekly build will become available later today, please give it a spin. Maarten, thanks for the good work on this bug!
Great stuff Maarten!
I've just tested it and it seems like it broke drag and drop from the task list into new email editor with Thunderbird, which used to work before. Dragging to folder on file system is working for both task list and editor handle.
Eugene: it works for me. If I drag via the editor I get the text copied to the email editor, if I drag from the Task List I get the file copied (changes detailed on bug 119556). Steffen, Maarten: should we make these two operations be consistent? It would be nice if they used the same code.
The shared code for the drag source of the task list and editor is in TaskListDragSourceListener. We could add a class to manage the supported transfer types.
(In reply to comment #50) > Eugene: it works for me. If I drag via the editor I get the text copied to the > email editor, if I drag from the Task List I get the file copied (changes > detailed on bug 119556). I though you've fixed that on bug 119556. Not sure if it went to the last weekly build, but dragging file to the attachment area in Thunderbird it is consistently does not work for dragging from both task list and the editor here. Dropping to the text area in Thunderbird email is pasting file url but I'd expect task description pasted.
(In reply to comment #49 and #50) > I've just tested it and it seems like it broke drag and drop from the task list > into new email editor with Thunderbird, which used to work before. Dragging to > folder on file system is working for both task list and editor handle. Well the code is shared now so should be pretty consistent ;-) It tries in order of decreasing completeness : 1) TaskTransfer - only supported for internal Mylyn stuff like drag to TaskList 2) FileTransfer - this zips the task and places the zip 3) TextTransfer - gives the URL as a piece of text It works like Eugene wants using Apple Mail on my Mac, but Thunderbird is unable to receive the FileTransfer, even from the Finder. So I think the problem is Thunderbird related. As a more general note: shouldn't we use URLTransfer for 3? see bug 100095 https://bugs.eclipse.org/bugs/show_bug.cgi?id=100095
