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

Bug 486626

Summary:	Add support class for the (un-)registration of visuals at the visual-part-map.
Product:	[Tools] GEF	Reporter:	Matthias Wienand <matthias.wienand>
Component:	GEF MVC	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	nyssen
Version:	0.2.0
Target Milestone:	4.0.0 / 3.11.0 (Neon) M5
Hardware:	All
OS:	All
Whiteboard:

Description Matthias Wienand

2016-01-27 03:29:14 EST

Registering and unregistering visuals at the visual-part-map is a responsibility of the IVisualParts. However, the currently implemented default mechanism for the (un-)registration does not involve updating the registration in case the visuals are changed by a call to IVisualPart#refreshVisual(). Moreover, since the registered visuals are not recorded, the unregistration has to walk over the whole visual-part-map to identify all entries that have to be removed. Therefore, a support class should be added to manage the (un-)registration of visuals at the visual-part-map. This support class can also record the registered visuals, so that the unregistration can be performed more efficiently, and can provide a convenience method for updating the registration that can be called by an IVisualPart after changing the visualization.

Comment 1 Alexander Nyßen

2016-01-28 15:38:22 EST

As already indicated in the forum (https://www.eclipse.org/forums/index.php/t/1074152/), IMHO a simple listener-based solution is appropriate here already, so no special support class would be needed.

Comment 2 Alexander Nyßen

2016-01-29 02:17:15 EST

(In reply to Alexander Nyßen from comment #1)
> As already indicated in the forum
> (https://www.eclipse.org/forums/index.php/t/1074152/), IMHO a simple
> listener-based solution is appropriate here already, so no special support
> class would be needed.

To make this more precise. It should be the adopter's responsibility to handle this. We should however clearly document this contract in IVisualPart and within createVisual(), refreshVisual(), and register/unregisterVisuals().

Comment 3 Matthias Wienand

2016-01-29 07:34:03 EST

Alexander and I discussed the issue in the office and concluded that the visual-part-map lookup should not depend on the visual parts registering all of their visuals. It is sufficient for the visual parts to only register their "main" visual (the one returned by #getVisual()). The visual-part-map lookup will then walk up the visual hierarchy until it finds a visual part for a visual. If no visual part can be found, the lookup resorts to returning the root part. Nonetheless, visual parts can decide to register all of their visuals to speed up the lookup, but that is not mandatory.

Consequently, I removed the registration of nested visuals, centralized the retrieval of an IVisualPart for a given visual within FXPartUtils#retrieveVisualPart(), and changed the Javadoc accordingly. The code is published on the master branch, therefore, I resolve this ticket as fixed for 3.11.0M5.