Summary: | GraphicalViewerImpl.findObjectAtExcluding() exclusionSet tested for IFigures instead of EditParts | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] GEF | Reporter: | Bryan Mising name <bryan> | ||||
Component: | GEF-Legacy GEF (MVC) | Assignee: | Alexander Nyßen <nyssen> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | minor | ||||||
Priority: | P3 | CC: | berthold.daum, bryan, jakub.mozgawa, nyssen | ||||
Version: | 3.6.1 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Bryan Mising name
2011-03-01 16:16:12 EST
You are right, this is indeed inconsistent. GraphicalViewerImpl should test for EditParts as well. There is GEF code depending on the current functionality, which could be changed quite easily: ConnectionEndpointTracker and DragEditPartsTracker (indirectly via TargetingTool#getExclusionSet()) seem to be the only GEF clients that pass in figures to be excluded from the search. However, there may be third-party code that depends on the current implementation. So we will at least have to announce the change. *** Bug 348358 has been marked as a duplicate of this bug. *** What will have to be investigated in terms of client code are subclasses of TargetingTool, overwriting getExlusionSet(), as well as subclasses of AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All other implementations seem to pass in an empty collection. (In reply to comment #3) > What will have to be investigated in terms of client code are subclasses of > TargetingTool, overwriting getExlusionSet(), as well as subclasses of > AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All > other implementations seem to pass in an empty collection. AbstractTransferDropTargetListener will be no problem, as the only subclass overwriting getExclusionSet() returns a list of edit parts, which is the correct contract. (In reply to comment #4) > (In reply to comment #3) > > What will have to be investigated in terms of client code are subclasses of > > TargetingTool, overwriting getExlusionSet(), as well as subclasses of > > AbstractTransferDropTargetListener, overwriting getExlusionSet() there. All > > other implementations seem to pass in an empty collection. > > AbstractTransferDropTargetListener will be no problem, as the only subclass > overwriting getExclusionSet() returns a list of edit parts, which is the > correct contract. Regarding the subclasses of TargetingTool, the implementation within ConnectionEndpointTracker may be easily migrated to provide a list of edit parts rather than their figures, while the other overwriting subclass, i.e. DragEditPartsTracker is a bit more problematic, as it puts the connection layer into the exclusion set. Created attachment 212504 [details]
Patch with proposed changes
I have create a patch that demonstrates how the current implementations could be adopted to restore the EditPartViewer#findObjectAtExcluding contract within GrahicalViewerImpl and its clients. I have the fear that restoring the contract will have to be paid with a decrease in performance (because the implementation within DragEditPartsTracker has to be adopted to traverse all edit parts with figures in the connection layer; at least this is how I currently see it), so I have not changed the code base yet but uploaded it as a patch for review.
Unassigning this and removing target milestone. This will not make it into 3.8.0, as we are past RC1 now. |