Bug 465090

Comment 1 Alexander Nyßen 2015-04-21 04:44:04 EDT

It seems the target node that is used to locate the click policy is not the visual of the FXGeometricCurvePart, thus the root part is located instead.

Comment 2 Alexander Nyßen 2015-04-21 05:06:49 EDT

The content part controlling the FXConnection is not located, as the target node is the CurveNode, not the FXConnection, and the hierarchy is not searched. Either we search the hierarchy or we ensure the FXCurceNode gets registered in the visual part map. 

Besides, the locating of click policies for all kinds of handles seems to be broken as well.

Comment 3 Alexander Nyßen 2015-04-21 05:15:07 EDT

We could add something like the following to AbstractFXContentPart to deal with the connection related problems:

// TODO: ensure this is not called when child visuals have already
	// registered
	@Override
	protected void registerAtVisualPartMap(IViewer<Node> viewer, N visual) {
		Map<Node, IVisualPart<Node, ? extends Node>> registry = viewer
				.getVisualPartMap();
		super.registerAtVisualPartMap(viewer, visual);
		// if we have children, register us for them as well
		if (getVisual() instanceof Parent) {
			for (Node child : ((Parent) getVisual())
					.getChildrenUnmodifiable()) {
				if (registry.get(child) == null) {
					registry.put(child, this);
				}
			}
		}
	}

	// TODO: ensure this is not called before child visuals have already
	// unregistered
	@Override
	protected void unregisterFromVisualPartMap(IViewer<Node> viewer, N visual) {
		Map<Node, IVisualPart<Node, ? extends Node>> registry = viewer
				.getVisualPartMap();
		super.unregisterFromVisualPartMap(viewer, visual);
		// if we have children, unregister us for them as well
		if (getVisual() instanceof Parent) {
			for (Node child : ((Parent) getVisual())
					.getChildrenUnmodifiable()) {
				if (registry.get(child) == this) {
					registry.remove(child);
				}
			}
		}
	}

It is important that a parent content part does not by mistake register itself for child visuals. I assume the fix listed above should preserve this property.

I have not looked into the handles problem yet.

Comment 4 Matthias Wienand 2015-04-24 04:16:11 EDT

I aligned the target part selection code for click events to be identical to that for drag events. Additionally, I ensured that the FXFocusAndSelectOnClickPolicy will only deselect everything when the background is clicked. This fixed both problems (handles and connections), nonetheless I also implemented the automatic registration of "nested" visuals, i.e. not controlled by another part, which allowed me to remove a few #registerAtVisualPartMap() and #unregisterFromVisualPartMap() methods.

The code is published on the master branch, therefore I resolve this ticket as fixed for 3.10.0M7.