How should event propagation be handled with the new TypedListener API?

[ptziegler]

In our application, we have a "container" composite, containing two controls. Whenever a listener is added to the composite, they are also added to the control by the overwritten addListener method:

@Override
public void addListener(int eventType, Listener listener) {
	super.addListener(eventType, listener);
	mTable.addListener(eventType, listener);
	mAutoCompleteTextWidget.addListener(eventType, listener);
}

There are other classes like this, but the general idea is all the same: Have a common interface so that one doesn't have to worry about the internal structure of the control.

With the changes done in 78943aa, this mechanism no longer works as most (if not all listeners) are added via the new addTypedListener() method, which internally calls _addListener(). So the method above is no longer called.

Because addTypedListener() is protected, I can't use the same approach for the new methods, as the call to mTable.addTypedListener(listener, eventTypes) is not visible.

My current workaround for this problem looks like this:

@Override
protected void addTypedListener(EventListener listener, int... eventTypes) {
	super.addTypedListener(listener, eventTypes);
	if (listener instanceof SWTEventListener eventListener) {
                TypedListener typedListener = new TypedListener(eventListener);
		for (int eventType : eventTypes) {
			addListener(eventType, typedListener);
		}
	}
}

However, SWTEventListener is not supposed to be used in client code, which leads me to my question:

Is there an intended way how this use-case should now be handled?

[HannesWell]

However, SWTEventListener is not supposed to be used in client code, which leads me to my question:

That's right and TypedListener isn't supposed to be used either.
The motivation to add addTypedListener() was to prepare a later deprecation for removal/hiding of both classes.

Because addTypedListener() is protected, I can't use the same approach for the new methods, as the call to mTable.addTypedListener(listener, eventTypes) is not visible.

Making it public should make it possible again to use your approach, shouldn't it?
In #1112 I made the method public since for all potential use-cases I saw it was sufficient and since visibilities should be as restricted as possible I went with this approach. But indeed, your use-case 'breaks' with that.
Since addListener() is already public and addTypedListener does not use special types I don't see a strong reason to not make it public if it is necessary.

Do you want to provide a PR to make it addTypedListener() public in the implementations of all three OS? Then we can discuss it with others.

[HannesWell]

Alternatively would it be a solution to override the type-specific methods to add listeners, like it was done in?
eclipse-tracecompass/org.eclipse.tracecompass#69

[ptziegler]

Do you want to provide a PR to make it addTypedListener() public in the implementations of all three OS? Then we can discuss it with others.

Making addTypedListener() would solve the problem but if the long-term goal is the deprecation and removal of (SWT)TypedListener, then this would just delay the problem. So I don't think that's a good solution.

Alternatively would it be a solution to override the type-specific methods to add listeners, like it was done in?

I think that might be the solution I will go with. At least based on our tests, we only care about the focusGained/focusLost events, meaning a minor adaption.

Thank you for your suggestion!