Remove the exclusion check for the TreeViewer

[ptziegler]

The collection of IFigures that is used in the findObjectAtExcluding() of the TreeViewer is compared against an EditPart. This check will always return "false" and is therefore obsolete.

Given that a TreeViewer is based on a Tree widget and not IFigure's, specifying an exclusion set is generally not supported.

[ptziegler]

@azoitl Given that you cleaned up the drag/drop listeners some time ago, perhaps you have more insight into this. As far as I understand, the exclusion list will always be empty for the TreeViewer, as the EditParts implement TreeEditPart and not GraphicalEditPart.

https://github.com/eclipse-gef/gef-classic/blob/3b9b44f49ff407d9b0b307643d546654f74107d5/org.eclipse.gef/src/org/eclipse/gef/dnd/AbstractTransferDropTargetListener.java#L89-L98

Meaning that the only way to exclude elements is by moving the excludes.contains(EditPart) to the Conditional and not the findObjectAtExcluding(...)?

Or to rephrase it: We would need different implementations of this method for the TreeViewer and the GraphicalViewer.

[azoitl]

@ptziegler when I cleaned that part I stopped at the treeviewer because I never could really grasp how this ever worked. The original documentation of the exclusion set said that it contains edit parts. However all implementations of graphical viewers and the classes using them always provided and expected IFigures. Except for the Treeviewer. Therefore I decided to change it the way it is now for all none Treeviewers. I agree that for treeviewers a different implementation would be needed.

[ptziegler]

The original documentation of the exclusion set said that it contains edit parts.

Thanks for the info. That's actually the reason that brought me to this topic, because that's how it (used to) work in WindowBuilder:

But I also dug up an old GEF 2.1.3 SDK and even there, the exclusion set was already using IFigures. So I somewhat doubt it has even been something else.

I'm currently playing around with the Outline viewer of the Logic editor and was wondering why the issue doesn't show up there. Because in principle, it should be possible to drag a tree item and drop it on one of its children. Turns out that the viewer contains some addition code to avoid this exact problem.

https://github.com/eclipse-gef/gef-classic/blob/3b9b44f49ff407d9b0b307643d546654f74107d5/org.eclipse.gef.examples.logic/src/org/eclipse/gef/examples/logicdesigner/edit/LogicTreeContainerEditPolicy.java#L61-L63

So yeah... I think this issue was never addressed and people just worked around it.

[ptziegler]

The original documentation of the exclusion set said that it contains edit parts. However all implementations of graphical viewers and the classes using them always provided and expected IFigures.

I just had a look at that and saw that you typified this method as part 49d0515fa7fc09bc6b35d47643f9cc26661fb5c3. In hindsight, I think this was the wrong choice, caused by misleading implementation and a wrong documentation.

Instead of an Collection<IFigure>, it probably should've been something like a Collection<?> that may either contain EditParts or IFigures. But there is not much that can be done now, so I think the correct approach is to adapt the implementation of the TreeViewer.

Right now I see the following options:

1. Always use a an empty exclusion for the tree viewer and do the filtering via the Conditional
2. Keep the exclusion as a raw type and suppress the warning. For the drag & drop listener, the corresponding methods should then be overridden to pass a set of EditParts.

[ptziegler]

Superseded by #904