Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add infrastructure for typed dataset plugins #1
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.
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.