Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 307279

Summary: Generalization of figure bounds to GeometricShape
Product: [Tools] GEF Reporter: Alexander Nyßen <nyssen>
Component: GEF-Legacy GEF (MVC)Assignee: gef-inbox <gef-inbox>
Status: RESOLVED WORKSFORME QA Contact:
Severity: enhancement    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Alexander Nyßen CLA 2010-03-27 05:40:08 EDT 
Build Identifier: M20100211-1343

Generalizing figure's bounds to paths would allow to better deal with clipping and rotation based issues, while on the other hand introducing of course much more complexity (and break a lot of existing API). IMHO it is however at least worth to be discussed, so I opened this bugzilla to have a place to collect pros and cons.

Having generalized bounds to paths, better support for rotation could be supported by introducing a general Transformable interface within draw2d.geometry package, subsuming translation, scaling, and rotation (and then only implemented by Paths), and to use this within coordinate system related calculations of figures (translateToRelative, translateToAbsolute, ...).



Reproducible: Always
Comment 1 Alexander Nyßen CLA 2011-02-03 12:14:21 EST 
As addressed by bug #307276, a common super interface for geometric shapes could be used instead of rectangle. It should offer to infer a rectangle for simple bounds checking (as well as a path represtentation). Adding a dependency to bug #307276, because this is a prerequisite. Setting milestone to "Future", because this is not alignable with the current API.
Comment 2 Alexander Nyßen CLA 2014-07-17 13:56:03 EDT 
As GEF4 does no longer rely on Draw2d for visualization (but instead on JavaFX, where things are more flexible because coordinate system transformations are actually handled via transforms), resolving this as WORKSFORME.
Comment 3 Alexander Nyßen CLA 2014-07-17 13:57:03 EDT 
(In reply to Alexander Nyssen from comment #2)
> As GEF4 does no longer rely on Draw2d for visualization (but instead on
> JavaFX, where things are more flexible because coordinate system
> transformations are actually handled via transforms), resolving this as
> WORKSFORME.

Which should mean that we do not need to enhance Draw2d to this extend, which would only be achievable by an API break anyway.