Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework SplitButton to not use SWT's internal TypedListener #582

Merged
merged 1 commit into from Apr 10, 2024

Conversation

HannesWell
Copy link
Member

The org.eclipse.swt.widgets.TypedListener should be considered an internal class (as the doc states) and leaks the class SWTEventListener which also resides in an internal package.

This reworks SplitButton to not use TypedListener anymore.

return evt;
};
for (Listener listener : selectionListeners) {
listener.handleEvent(eventFactory.get());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it looks wrong to create a new event for each listener, @lcaron what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It used to be like that, this is why I replicated it.
But when looking at SWT I get the impression that there is only one Event send to all listeners, unless one uses a typed listener (e.g. SelectionListener), then the one event is wrapped in a new SelectionEvent for each SelectionListener, see TypedListener. But the latter is probably a technical detail.
And although Events are not immutable, I think good listeners don't change events.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for "doit" when the event has that sort of thing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for "doit" when the event has that sort of thing.

Didn't knew that, thanks for the hint. So maybe there should be one Event send to all Listeners and a new SelectionEvent for each SelectionListener?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's how SWT generally does it...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And although Events are not immutable, I think good listeners don't change events.

Actually listeners can give some things back to the caller (e.g. as mentioned doit), there is even a field data mentioned for "application use" in TypedEvent, I think if one can install listeners to an SWT object one should always be "nice" and only ever modify things if the API tells so.

@merks
Copy link
Contributor

merks commented Mar 23, 2024

Unless bounds are changed that will allow this latest Nebula bundle to only installed along with latest version of SWT, this type of change is going to cause grief.

If it were "my project" I would probably try to create a utility that allowed me to work reflectively with both the old "APIs" and the new APIs so that these things continue to "just work".

@HannesWell
Copy link
Member Author

Unless bounds are changed that will allow this latest Nebula bundle to only installed along with latest version of SWT, this type of change is going to cause grief.

This change does not use the recent API addition in SWT (as you can see in the CI it builds with the latest SimRel) and just avoids TypedListener by reworking the listener handling. I assume that's the source of your concern, isn't it?
Although I don't know if this is compatible with SWT 1.0, but it shouldn't raise the requirements on the SWT version compared to the previous state.

If it were "my project" I would probably try to create a utility that allowed me to work reflectively with both the old "APIs" and the new APIs so that these things continue to "just work".

The new APIs are only used in #583, but there I raised the version bounds. But lets discuss there if any other strategy should be used.

@merks
Copy link
Contributor

merks commented Mar 23, 2024

Sorry, I didn't look in detail of what's being used!

@HannesWell HannesWell force-pushed the rework-splitbutton branch 2 times, most recently from f806c5f to 81bba97 Compare March 24, 2024 14:33
@HannesWell
Copy link
Member Author

@lcaron, @wimjongman can you please review this as well?
This only uses already existing SWT API.

Copy link
Contributor

@wimjongman wimjongman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One remark. Otherwise LGTM. I did not run it so I don't know if the widget works the same way it used to.

@HannesWell
Copy link
Member Author

One remark. Otherwise LGTM. I did not run it so I don't know if the widget works the same way it used to.

I'm not familiar with Nebula in general and the SplitButton especially, but when I run the SplitButtonSnippet everything seem to work fine as far as I understood it.

@HannesWell
Copy link
Member Author

@wimjongman is there anything missing here or can this be submitted?

@wimjongman
Copy link
Contributor

Go for it. Thanks, Hannes!

@merks merks merged commit 59eb85c into eclipse:master Apr 10, 2024
3 checks passed
@HannesWell HannesWell deleted the rework-splitbutton branch April 10, 2024 11:29
@HannesWell
Copy link
Member Author

Go for it. Thanks, Hannes!

I'm not a committer here, but thanks Ed for submitting.

@wimjongman
Copy link
Contributor

Go for it. Thanks, Hannes!

I'm not a committer here, but thanks Ed for submitting.

You get a special mention when we release. 🏅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants