[ImageJ-devel] Overriding min, max and choices at runtime

[Johannes Schindelin]

Hi,

On Mon, 20 Jun 2011, Grant B. Harris wrote:

> Can we not, alternately, create a plugin that doesn't use @Parameters? 
> This is possible, is it not? I can imagine someone wanting to build a 
> plugin that has some crazy custom input widgets...

The idea of @Parameter was to simplify implementations of plugins. If the 
design still simplifies matters even when you want to allow callbacks then 
that should be the preferred method. If it complicates things, it should 
not be used in that case.

Having said that, I could imagine that something like

	@Parameter(getMin = "getMinValue")
	public double value;

	...

	public double getMinValue() {
		return image == null ? 0 : -image.getWidth();
	}

could be easy enough. I am just afraid that we'll have method creep that 
way (remember: every method has at least 4 lines and you might need a 
couple of callbacks per parameter), and that it might be a better idea to 
have something like

	@Parameter(getLimits = "getLimitsValue")
	public double limits;

	...

	public void getLimitsValue(DoubleLimits limits) {
		if (image == null)
			return;
		limits.min = -image.getWidth();
		limits.max = image.getWidth();
		limits.step = 1;
	}

with a class

	public class DoubleLimits {
		public double min, max, step;
	}

might be more appropriate... Hmm?

(One could also think of automatic getLimits<name>() methods, i.e. when 
there is a parameter called "grant" and there exists a method 
getLimitsGrant() it gets called, but that would be a bit too magic for my 
liking; it's not intuitive.)

> Another idea... could there not be a way to intercept the InputPanel 
> after creation, modify it (and then one would need to intercept the 
> 'harvesting' step ...).... Hmmm...

I am afraid that these plugins would not be useful outside GUIs. For 
example, if you would want to concoct a macro, say, in a web browser, and 
run it inside an OMERO database on hundreds of thousands of images, then 
there would not be an InputPanel.

(Of course we could repeat ImageJ's design of making GUI elements 
mandatory even for offline processing, but that design imposes rather 
serious limitations IMO. In general, processing should not be thought of 
as GUI centric, otherwise there is no proper separation of concerns.)

Ciao,
Dscho