Community
Participate
Working Groups
There are a lot of SWTUtil classes in various projects, and other things like that that have similar or identical implementation of the same set of utility methods. To start with we should make a single implementation of this in SWT so that the other versions can gradually be removed (and the main implementation enhanced as required). This would be an excellent project for a SOC student, and Dave Carver has someone in mind.
SWT won't do this. We can't decide which methods are used (good) and which ones are not. It's up to application code to share code how it sees fit, not a system library. Is UI interested in owning the SWTUtil to rule the world?
This actually is a good thing, that needs to happen. Too many places are duplicating common utility classes and methods, just because they aren't available as API. This type of refactoring while it can affect a lot of projects is long term a good thing to do. I'd mark this as bug day at least to get some community help, but Steve you are right, it needs a home...Hopefully though it doesn't become a Not In My Backyard item.
Aww geez, not in my backyard...
JFace is an obvious choice, but we would need to be specific - how much code duplication is there in the Eclipse SDK (and beyond)?
Dave, maybe Laknath can do this research? There are some classes in org.eclipse.ui.navigator.tests called DisplayHelper, DisplayWaiter, and SWTEventHelper that might contain similar functionality as SWTUtils. Maybe searching for certain method names will yield good results.
*** This bug has been marked as a duplicate of bug 253798 ***