[ImageJ-devel] (headless) command execution

[Stefan Posch]

Hi Curtis,

regarding the concept of initializers I had a discussion with Birgit yesterday
and we came up with the following ideas.

We think we could do without command and parameter initializers but work only with
the parameter's callback function which - as currently - are to be invoked 
upon setting/changing the corresponding parameters value.

As currently, depending on parameter values, e.g. the image assigned to a Dataset,
the command may add (or remove) parameters. This would be accomplished
by the callback functions of the parameter whose value is the cause for these new parameters.
E.g. the callback function of the inputDisplay of DuplicateImage would add the parameters
(which is currently done by the command initializer).
If some parameters should get (initial) values depending on the value of other
parameters (e.g. your example of setting default brightness/contrast min,max values
to current min,max of the input image) would we again the responsibility of 
the callback function of the cause, i.e. the input image.

This would eleviate us of the need to fill in parameters required for the command initializer.
If a parameter's value is set (either by a pre processor or programmatically)
its callback function takes care of taking the apropriate actions.

If the pre processor is run, it just needs to set the parameter values it decides to,
and the callback functions would be could automatically.

What remains is of course: 
(i) assume a parameter's value is changed, and its callback method
  called accordingly. What if this callback reqires/assumes one or several other parameters
  to aready have be set? It seems to be, that this necessarily is the responsibility
  of the callback function (resp. its programmer) to handle this. I.e. to check
  the validity of other parameters it requires. Otherwise the Command or its Parameters
  have to declare a predefine order in which parameters have to be set.
  (Which we have considered to introduce to alida/mitobo few years ago but abandoned this
  idea as it seems to messy/error prone.)
(ii) in case of command execution via GUI (in contrast to programmatically):
    what if not all parameters which add further parameters are
    filled before the GUI is created and presented to the user and are set by the user?
    What we are considering is that the GUI to figure out such events have happened
    and then to adapt the GUI accordingly.

    How to figure out that set set of parameter (or the type of an already existing parameter)
    was change by a callback function?
    We see two possibilities: 
    (a) a parameter may announce via its annotation that it (occasionally)
        _may_ change paramter definitions and the GUI always assumes that this had happend,
        is such a parameter's value has changed (which the GUI knows at it controls this processes).
    (b) the callback function is to fire events in case it changes parameter definitions.

    (a) might be similar or be used in analogy to your idea of a parameter to announce "required before initialize",
       as the pre processor framework would know that setting of such a parameter probably/potentially
       may add parameters and should better be set before creating the GUI to ask the user for
       further parameters (and if it accomplishes to set all of those parameters and either excludes them from
       the GUI - as currently done by IJ2 for input images - or prohibits changing these parameters,
       we get rid of problem (i) stated above).


To make things conceptionally easier (for me) I favour the following guideline:
A parameter, e.g. inputDisplay, may add (or remove) parameters to the command
exclusively depending of its own value. Furthermore the parameter (names) potentially
added by this parameter are disjoint from those parameters added by other parameters of
the command. However, it is probably not possible to check or enforce this restriction.
As stated above in (ii) in my view it would be the task of the programmer of the Comand anyway
to cope with more complicated situations and does not affect to supporting "runtime system",
e.g. the functionality to run pre processors and creating GUIs to harvest input vlaues from the user.


Best regards

Stefan

PS.:
A different issue I came across have a second look at the Parameter annotation, sepcifically
its choices: The few examples of usage I had a look at are parameters of type String which
announce valid values. It might me worth considering to drop this feature and use Enums instead
of Strings which easily allows to generate an approprate selection by the GUI.
-- 
Prof. Dr.-Ing. Stefan Posch,
        Institut fuer Informatik, Martin-Luther-Universitaet Halle-Wittenberg
        Von-Seckendorff-Platz 1, 06099 Halle (Saale)
phone:  ++49 345 55-24728
fax:	++49 345 55-27039
e-mail: Stefan.Posch at informatik.uni-halle.de
www:    www.informatik.uni-halle.de/~posch/