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

Move non-Swing-specific object handling upstream #73

Open
ctrueden opened this issue Sep 5, 2022 · 1 comment
Open

Move non-Swing-specific object handling upstream #73

ctrueden opened this issue Sep 5, 2022 · 1 comment

Comments

@ctrueden
Copy link
Member

ctrueden commented Sep 5, 2022

See e.g. #72. The logic for whether to use SwingObjectWidget belongs in the abstract layer in scijava-common, so that other UI implementations benefit as well.

@imagejan
Copy link
Member

imagejan commented Sep 6, 2022

I tried moving the logic from SwingObjectWidget here:

return super.supports(model) && ((model.getChoices() != null && model.getChoices().length>0) ||
((model.getObjectPool() != null) && (model.getObjectPool().size() > 0)));

... into the ObjectWidget interface like this:

	@Override
	public default boolean supports(final WidgetModel model) {
		return InputWidget.super.supports(model) && ((model.getChoices() != null && model.getChoices().length > 0)
				|| ((model.getObjectPool() != null) && (model.getObjectPool().size() > 0)));
	}

... but I cannot call ObjectWidget.super.supports in SwingObjectWidget because there's a more specific override in AbstractInputWidget.

@ctrueden What's the right way to put that logic in the hierarchy of abstract classes and interfaces?

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

No branches or pull requests

2 participants