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

Add infrastructure for typed dataset plugins #1

Open
ctrueden opened this Issue May 1, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@ctrueden
Copy link
Member

commented May 1, 2014

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

This comment has been minimized.

Copy link
Member

commented May 1, 2014

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

This comment has been minimized.

Copy link
Member Author

commented May 1, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.