search

imagej / imagej-common

ImageJ core data model
https://imagej.net/libs/imagej-common
BSD 2-Clause "Simplified" License
9 stars 18 forks source link

Add infrastructure for typed dataset plugins #1

Open ctrueden opened 10 years ago

ctrueden commented 10 years ago

It would be nice if we provided a template class for designing plugins that only work with certain types of Datasets. For instance the user might make a plugin that only works with unsigned byte type data. (This is similar to IJ1's DOES_RGB, DOES_ALL, etc.) We need to provide ways to get the type of a Dataset for checking. If we could make the template class check parameters at init time (and not when run() is called) that would be great. This would simplify plugin developers lives.

However a template class approach may be too limiting in that we really need multiple inheritance to cover the flexibility of our other plugin base class implementations. So maybe instead we provide interfaces and helper methods.

Another possibility is to have all plugins have a precheck() method with current abstract base classes providing empty ones. And plugin developers could provide their own implementation. The precheck would happen after @Parameters assignment and maybe after initializers were run but before run() is ever called.

(See also ImgPlusService.)

Migrated-From: http://trac.imagej.net/ticket/1945

tnargsirrah commented 10 years ago

Ideally, a command/action would (dis)enable on the menu if the current selection is (not) of the correct type. This would necessitate knowing the acceptable types when the commands are installed/initialized.

ctrueden commented 10 years ago

I have seen two schools of thought on that. Some people argue that graying out menu items is suboptimal, because there is no feedback on why a given menu item is grayed out. On the contrary: if you are allowed to invoke the command, but then are told why the current program state is not appropriate to that command, then you have more information about how to proceed.

So, since graying out menu items turns out to be surprisingly tricky within our current architecture, I am inclined to wait till we have a really clear need for it, before pursuing a mechanism to achieve it.

But I do agree that for a variety of reasons, it would be nice to have a little more metadata about what sorts of images work with what sorts of commands. However, perhaps the ImageJ OPS framework already achieves this goal with its "method overloading" approach to operations.