[ImageJ-devel] @parameter choice update in component callback
Curtis Rueden
ctrueden at wisc.edu
Thu Aug 20 17:13:11 CDT 2015
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>
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
> http://imagej.net/mailman/listinfo/imagej-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150820/d0ea3742/attachment.html>
More information about the ImageJ-devel
mailing list