[ImageJ-devel] @parameter choice update in component callback

Mon Aug 24 04:41:53 CDT 2015

Hi Adrian, Jan and Curtis

I went through the tutorials and found about the initialisation method. Curtis was absolutely right about what I wanted to do. Thanks for the detailed explanations. In fact I was aiming for the use case 4) update parameter attributes several times during callbacks. Since the file chooser could have its input changed several times (typically a click accident, mistake of choice or such), It would be odd for the user if the UI get’s updated only once.

The alternative of course is to use an OpenDialog previous to the configuration dialog. Or to program the the dialog from scratch (but this certainly does not improve reusability neither).

The proposal https://github.com/scijava/scijava-common/issues/181 sounds like a promising idea to me.

Felix

On 22 Aug 2015, at 6:10 , Curtis Rueden <ctrueden at wisc.edu<mailto:ctrueden at wisc.edu>> wrote:

Hi Adrian,

> Doesn't that allow doing what Felix would like to do, by populating
> the combobox through such an initialiser ?

I think what Felix wants is to set a parameter's "choices" attribute -- i.e., the values that will appear in the input harvester UI's dropdown list box.

It can be done with a DynamicCommand, but right now it only works from an initializer, not from a callback. So if you want to populate the choice once from, say, the active Dataset, it works. But if you want to update the choices e.g. every time the user moves a numerical slider, it will not work because the UI will not update.

See also:
* https://github.com/scijava/scijava-common/issues/180
* https://github.com/scijava/scijava-common/issues/181

> Are the parameters populated/initialised in the order they appear? In
> particular, is the initialisation done serially or can there be
> parallel execution of initialisers ?

Initialization is currently implemented serially [1].

> I have parameters a, b, c whose initialisation depend on a common
> calculation (depending on the image gotten through a previous
> @Parameter ImagePlus imp): can I do this calculation in the
> initialiser for the first parameter a, and then in the initialisers of
> b and c rely on the fact that the calculation was already done ?

Perhaps simplest at the moment would be to give your command a global initializer -- i.e., set the initializer method in the @Plugin annotation itself, rather than on specific parameters. The ImagePlus will be populated by a preprocessor _before_ the initialize method is called, so when your global initializer gets called you will already have access to the ImagePlus.

But again, scijava/scijava-common#181 is very relevant here.

Regards,
Curtis

[1] https://github.com/scijava/scijava-common/blob/scijava-common-2.42.2/src/main/java/org/scijava/module/AbstractModule.java#L75-L88

On Fri, Aug 21, 2015 at 6:18 AM, Adrian Daerr <adrian.daerr at univ-paris-diderot.fr<mailto:adrian.daerr at univ-paris-diderot.fr>> wrote:
Hi Curtis, Felix, Jan, and others,

In the CommandWithPreview tutorial example[*] that Curtis sent to
the list a few weeks back, there is a @Parameter which is
initialised to a value depending on the initialisation of another
parameter:

@Parameter private ImagePlus imp;

@Parameter(persist = false, initializer = "initTitle") private String title;

/** Initializes the {@link #title} parameter. */
protected void initTitle() {
        title = initialTitle = imp.getTitle();
}

[*]
https://github.com/imagej/imagej-tutorials/blob/master/commands-with-preview/src/main/java/CommandWithPreview.java

Doesn't that allow doing what Felix would like to do, by
populating the combobox through such an initialiser ?

Are the parameters populated/initialised in the order they
appear? In particular, is the initialisation done serially or can
there be parallel execution of initialisers ? I ask because I
have parameters a, b, c whose initialisation depend on a common
calculation (depending on the image gotten through a previous
@Parameter ImagePlus imp): can I do this calculation in the
initialiser for the first parameter a, and then in the
initialisers of b and c rely on the fact that the calculation was
already done ?

cheers,
Adrian

On Thu, 20 Aug 2015 17:13:11 -0500
 Curtis Rueden <ctrueden at wisc.edu<mailto:ctrueden at wisc.edu>> wrote:
Hi Felix, Jan and everyone,

I couldn’t find any hint that it is possible to update the choices of
a parameter (declared with the annotator) in a callback that for
another parameter.

It is possible to dynamically adjust parameters from Java code [1]. You can
also dynamically add and remove parameters. Such commands extend the
DynamicCommand class.

There are many examples currently in the imagej-plugins-commands project;
e.g.:
https://github.com/imagej/imagej-plugins-commands/blob/imagej-plugins-commands-0.5.1/src/main/java/net/imagej/plugins/commands/restructure/AddAxis.java

However, a couple of notes:

- This pattern makes the command less reusable from other contexts, because
some contexts require a priori knowledge about the number and types of
input and output parameters.

- The user interface currently does not properly refresh the input
harvester dialog if changes are made to parameters from a callback. So
while you can technically do things like change the choices array of a
multiple-choice input, the user will not actually see it.

- What does work currently is to determine the multiple-choice values at
initialization time, based on the values of parameters which have already
been populated earlier, such as an active dataset. This is what many of the
DynamicCommand implementations in imagej-plugins-commands do.

Really, there are _five_ different classes of commands here:

1) Totally fixed, with inputs and outputs known in advance.
2) Updates parameter attributes (such as choices—but not # or type of
inputs/outputs) once during initialization.
3) Updates parameter number and type (i.e., adding/removing inputs/outputs)
once during initialization.
4) Updates parameter attributes repeatedly e.g. during callbacks.
5) Updates parameter number and type repeatedly e.g. during callbacks.

Of these, type #1 is most desirable for a variety of reasons. Failing that,
types #2 and #3 can be done right now using DynamicCommand and it works
properly from the ImageJ UI—but not from other contexts like CellProfiler,
KNIME, etc. Types #4 and #5 can also be coded but will not work properly
from the UI in ImageJ because the input harvester is not rebuilt on
callbacks.

See also:
* https://github.com/scijava/scijava-common/issues/42
* https://github.com/scijava/scijava-common/issues/43
* https://github.com/CellProfiler/CellProfiler/issues/647

Regards,
Curtis

[1] Dynamically updating parameters from scripts would be a different
story. No plans to do that any time soon...

On Thu, Aug 20, 2015 at 6:50 AM, Jan Eglinger <jan.eglinger at gmail.com<mailto:jan.eglinger at gmail.com>>
wrote:

Hi Felix and all,

On 20.08.2015 10:06, MEYENHOFER Felix wrote:

I couldn’t find any hint that it is possible to update the choices of a
parameter (declared with the annotator) in a callback that for another
parameter. For example; I have a file chooser and once a file hase been
chosen, I want to read some file metadata and then update the choices of
the combobox that allows to select the images series.
Since I could not figure a way to do it, I wanted to ask here if it is
possible at all?

I think dynamic adjustment of parameters isn't possible currently, but I
agree that it would be a great thing to have.

I know quite some use cases where either a DialogListener or a series of
subsequent dialogs are used in ImageJ 1.x plugins to adjust parameter
choice to previously harvested input.

Furthermore, is it possible to get a directory chooser instead of a file
chooser in the configuration dialog of a command using the @Parameter
annotation?

Yes, by using the
    style = "directory"
attribute. See *Templates > Python > Process Folder* in the script editor,
and this related discussion:
  https://github.com/imagej/imagej-legacy/pull/114

Best,
Jan

_______________________________________________
ImageJ-devel mailing list
ImageJ-devel at imagej.net<mailto:ImageJ-devel at imagej.net>
http://imagej.net/mailman/listinfo/imagej-devel

--
http://www.msc.univ-paris-diderot.fr/~daerr/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150824/a94ba250/attachment-0001.html>