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 <ctrue...@wisc.edu<mailto:ctrue...@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.da...@univ-paris-diderot.fr<mailto:adrian.da...@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 <ctrue...@wisc.edu<mailto:ctrue...@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.eglin...@gmail.com<mailto:jan.eglin...@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@imagej.net<mailto:ImageJ-devel@imagej.net> http://imagej.net/mailman/listinfo/imagej-devel -- http://www.msc.univ-paris-diderot.fr/~daerr/
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
