List<Shape> Module parameter interpreted as napari layer

[gselzer]

Trying to run the op morphology.dilate(img "out"?, img "in1", list "in2", boolean "isFull"?) -> (img "out"?) yields a widget that provides a layer selector for in2.

Unfortunately, this will probably be a tricky issue to fix, because we are dealing with java generics, and we already have a complicated widget for dealing with Shapes.

[ctrueden]

I suggest to encapsulate all the various places you call ModuleItem.getType() throughout the codebase into a single utility function that computes the Pythonic type hint from the ModuleItem. Then, you can refactor to call getGenericType() instead of (or in addition to) getType(), and have some case logic around "easy" cases like ParameterizedType of collections. And later we could even push such logic up into scyjava.

[gselzer]

I suggest to encapsulate all the various places you call ModuleItem.getType() throughout the codebase into a single utility function that computes the Pythonic type hint from the ModuleItem.

Yup, the function is type_hint_for

[gselzer]

I looked a little more into why this is failing. Here's what's happening:

1. The OpListing reduces ListDilate's parameters down to their raw types, via the default type reducer. Therefore, the List<Shape> parameter becomes a List parameter
2. napari-imagej, in the attempt to find a suitable type hint, finds that ImageDisplays can be converted to a List, and recommends the corresponding python type, a napari Image layer, as the input type.

As a result, I think that the OpSearcher needs to have a bit more intelligence in creating the OpListings, especially w.r.t. type parameters. Iirc this change was made to avoid the distinction between, for example, Img<IntegerType> and Img<RealType> showing up as two separate signatures, and I still think that's nice.

We could also make some changes in napari-imagej to solve this, but I'm guessing Fiji will see similar issues, so maybe we should just fix it in Ops?