Bugzilla – Full Text Bug Listing
| Summary: | [Tool] SelectionTool don't use the EditPart.getTargetEditPart | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Simon Bernard <sbernard> |
| Component: | GEF-Legacy GEF (MVC) | Assignee: | Alexander Nyßen <nyssen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | contact, dsciamma, nyssen |
| Version: | 3.3.2 | ||
| Target Milestone: | 3.7.1 (Indigo) M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
I asked a question on GEF newsgroup ... no answer ... I opened a bug .... no answer ... I change this bug's severity from "enhancement" to "normal", hoping to have a sign of life !! ;) Simon, while I cannot make it undone, I am sorry you have not obtained any reaction to your request up to now. Concerning what you have stated, I agree that it is an inconsistency that SelectionTool does not evaluate getTargetEditPart(), because e.g. MarqueeSelectionTool does.
However, as isSelectable() is explicitly meant to infer, whether an edit part is selectable or not I think it should explicitly get called here as well (because even the default implementation may return a non-selectable edit part, if an attached edit policy feels responsible and returns such a one).
Therefore, I changed the implementation to:
protected EditPartViewer.Conditional getTargetingConditional() {
return new EditPartViewer.Conditional() {
public boolean evaluate(EditPart editpart) {
EditPart targetEditPart = editpart
.getTargetEditPart(getTargetRequest());
return targetEditPart != null && targetEditPart.isSelectable();
}
};
}
This way, the flexibility you request is nevertheless gained (and the inconsistency with other tools is removed).
Committed all changes to cvs HEAD (3.7).
|
Build ID: 20070814-1555 Steps To Reproduce: 1.In your code, override the getTargetEditPart to make it return null; 2.Run your application. 3.Use selectingTool. 4.Click on an EditPart. 5.You can select it... So the SelectionTool don't use the EditPart.getTargetEditPart More information: I don't understand why the SelectionTool overrides getTargetingConditional with : protected EditPartViewer.Conditional getTargetingConditional() { return new EditPartViewer.Conditional() { public boolean evaluate(EditPart editpart) { return editpart.isSelectable(); } }; } Why not just letting the TargetingTool implementation ... protected EditPartViewer.Conditional getTargetingConditional() { return new EditPartViewer.Conditional() { public boolean evaluate(EditPart editpart) { return editpart.getTargetEditPart( getTargetRequest())!= null; } }; } It could allow to customize filter targeting at EditPart level... Besides, the default implementation of getTargetEditPart is : public EditPart getTargetEditPart(Request request) { EditPolicyIterator i = getEditPolicyIterator(); EditPart editPart; while (i.hasNext()) { editPart = i.next() .getTargetEditPart(request); if (editPart != null) return editPart; } if (RequestConstants.REQ_SELECTION == request.getType()) { if (isSelectable()) return this; } return null; } and so this modificatoin don't change the default behaviour and add more flexibility!