scijava / scijava-ui-swing

SciJava UI components for Java Swing.
BSD 2-Clause "Simplified" License
7 stars 11 forks source link

Move non-Swing-specific object handling upstream #73

Open ctrueden opened 2 years ago

ctrueden commented 2 years ago

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 commented 2 years ago

I tried moving the logic from SwingObjectWidget here:

https://github.com/scijava/scijava-ui-swing/blob/3c3317fe25a0b5f3ab167ee1e5b2ea6ba4af11c8/src/main/java/org/scijava/ui/swing/widget/SwingObjectWidget.java#L99-L100

... 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?