Community
Participate
Working Groups
I would like to be able to extend the TaskListDropAdapter, in particular to add custom behaviour when a task is dragged onto another task if some modifier key is held.
Created attachment 210344 [details] patch Something like this could work. I'm not sure what the dragOver method was doing other than changing the drag icon, and I think it makes more sense to indicate that dragging to a repository task without modifiers is not allowed, which this does.
Created attachment 210345 [details] mylyn/context/zip
Sam, can you provide an example what kind of behavior extensions would implement? I'm worried that if we make DnD extensible it's going to be very hard to predict for users what happens when they drag and drop. Also this seems very difficult to discover.
Created attachment 210391 [details] tooltip That's part of the reason I want to restrict it to dragging tasks onto repository tasks - this is something which currently has no effect (although the UI makes it look like it will do something), and the behaviour for other kinds of drags will not be able to be changed. In this case, there is a connector which has a field for listing related tasks in other repositories. I would like to be able to add a task to that field by dragging in the task list. I agree this is not easy to discover - it would be a more advanced feature that users of the connector would most likely have to read about, as a shortcut to opening the task and editing the field directly. We could also consider popping up some kind of tooltip on drag to inform the user of what will happen, similar to what Windows does (see attachment).
> this is something which currently has no effect Last time I looked at the drop adapter, it had only an effect for local tasks to move the task to the same container (eg category), a behavior I really didn't expect ;)
(In reply to comment #5) > > this is something which currently has no effect > Last time I looked at the drop adapter, it had only an effect for local tasks to > move the task to the same container (eg category), a behavior I really didn't > expect ;) Right, dragging onto _repository_ tasks has no effect.
I like how Windows shows the action that is happening. Can we do something similar with SWT? I really like the idea of adding associations through drag and drop. My sense is though that the drag and drop handler is not the right point to provide this extensibility. I would prefer if we added support for creating associations to the framework to support this for any connector that has these kind of associations. This is also related to bug 341307: Support local tasks as subtasks of repository tasks.
Rather than allowing overriding of DnD behaviour, which could be problematic, it would be sufficient to provide a notification mechanism for when tasks are dropped on other tasks. I have pushed a code review.
Thanks! Can you move the review to the master branch? It looks like it's currently building against the e_3_7_m_3_6_x branch: http://review.mylyn.org/#change,255
How do I do that? Do I just rebase my branch on master?
(In reply to comment #10) > How do I do that? Do I just rebase my branch on master? Yes, that should do the trick. You can then push the rebased branch again and it should create another patch set.
review: http://review.mylyn.org/#change,255
I have commented on the review. It'd be great if you addressed the nits and attached a patch.
Shawn has pointed out that it would make sense for clients to also be notified when a task is dropped into the task editor, instead of trying attach an xml.zip file. I will look into adding that as part of the same notification mechanism, with another Operation type: public static enum Operation { COPY, LINK, DROP_ON_TASK_EDITOR };
We may also want to consider the same event mechanism for tasks in the search view.
(In reply to comment #15) > We may also want to consider the same event mechanism for tasks in the search > view. I wasn't able to quickly see a way to do that and I probably won't have time to look into it further for this release.
(In reply to comment #16) > I wasn't able to quickly see a way to do that and I probably won't have time to > look into it further for this release. Sounds good. We can always add that later if needed. I have commented on the latest patch set. I'd be great if you could address the last two nits and then attach a patch. Thanks!
Created attachment 211068 [details] patch
It doesn't apply cleanly. Please rebase/merge against the latest master.
I take that back, I had the wrong branch. Merging now.
Great contribution! I have applied the patch to master.
