Re: "No" button within GenericDialog class feature update

Posted by Michael Schmid on
URL: http://imagej.273.s1.nabble.com/No-button-within-GenericDialog-class-feature-update-tp5022458p5022465.html

Hi Philippe,

for a preview-like function as you describe it, I think we definitely
need callback. In many cases, a button won't be necessary, however: E.g.
the case of several Plot menus, such as "More>>Set Range..." and
"More>Axis Options...", the changes could be done immediately, as it is
done for the "More>>Contents Style..."
In such a case, what would be required is just keeping the old settings
in memory, to revert to them in case the user presses the 'Cancel'
button. The plugin should register as DialogListener and have a
DialogItemChanged method that does the work, instead of doing it in the
code after closing the dialog. To get it working with macros, the
DialogItemChanged method should be called once after the dialog is done
(this could be restricted to macros).

The PlotContentsDialog class is an example of such a DialogListener
(though with a different strategy for macros, and rather complex), the
SpecifyROI class (Edit>Selection>Specity...) is another one.

This approach would do the work in the EventQueue, blocking the user
interface, so it is not well-suited for calculations that take longer
than a short fraction of a second. In that case, when working on an
image, you could use the preview functionality of the
ExtendedPlugInFilter class.

Concerning the Plot class: I am aware that the "More>>Set Range..." and
"More>Axis Options..." should have immediate preview, and there should
be also menu variants just for the x axis and y axis, which should ber
linked to double-clicking on the label and number area. The PlotDialog
class is written to allow for this change, but it has to be done (just
some work).



@Herbie: for applications like this, where the button does no real
action, it would not break the macro recording functionality.


Michael
________________________________________________________________
Michael Schmid                    email: [hidden email]
Institut für Angewandte Physik, Technische Universität Wien
Wiedner Hauptstr. 8-10/E134, 1040 Wien, Austria
Tel. +43 1 58801-13452, Fax +43 1 58801 13499
________________________________________________________________

On 25.09.19 00:55, CARL Philippe (LBP) wrote:

> Hi Michael,
>
>> Philippe, which type of applications did you have in mind?
>
> What I had in mind is exactly what you described below:
>
>> However, the applications I have in mind are more in the spirit of
>> 'preview', doing some actions that allow the user to refine the
>> parameters, showing additional information.
>
> More precisely, I want this customized 'No' button to do exactly the same thing than the 'Ok' button, but without closing the dialog and thus not having to go back and forth between opening the Dialog box, change the set values and having the Dialog closed by the dispose method.
>
> Let's take as example code you had written within the Plot classes, where within the More>>Set Range... submenu, it is not possible to see the effect of new values settings without having the submenu closed and thus having to reopen it.
>
>> Is it something where macro recording would make sense?
>
> I guess the update I'm thinking about is still compatible with macro recording fetures, isn't it?
>
> Nevertheless your suggestion of having the possibility to define an array of buttons is going way further than my idea (even if I would be cool to have such features).
>
> Good night!
>
> Philippe
>
> ----- Mail original -----
> De: "Michael Schmid" <[hidden email]>
> À: "imagej" <[hidden email]>
> Envoyé: Mardi 24 Septembre 2019 19:26:23
> Objet: Re: "No" button within GenericDialog class feature update
>
> Hi Herbie,
>
> without additional effort the actions done by the button(s) would not be
> macro-recordable.
> I also don't see a clear concept for macro recording of buttons in the
> general case: If the user sets some value, presses a button, sets
> another value in the same field, presses a button, and the result
> depends on what has been done in what sequence, one would have to record
> more than one value for a given field, This is incompatible with the
> ImageJ concept of macro recording.
>
> However, the applications I have in mind are more in the spirit of
> 'preview', doing some actions that allow the user to refine the
> parameters, showing additional information.
> Or in a NonBlockingGenericDialog let the user do some selection (highly
> interactive things that are not macro-recordable anyhow, unless, say the
> selection coordinates go numeric fields of the dialog and will be
> recorded that way).
>
> Philippe, which type of applications did you have in mind?
> Is it something where macro recording would make sense?
>
> ---
> I can't say anything concerning macro recording of the ImageJ2-style
> interface; I did not venture beyond ImageJ 1 so far.
>
>
> Best,
>
> Michael
> ________________________________________________________________
> On 24.09.19 19:05, Herbie wrote:
>   > Good day!
>   >
>   > Are the proposed approaches (especially "ImageJ2-style Command")
> compatible with the GenericDialog and as such macro-recordable as usual?
>   >
>   > I plead for compatibility with the convenient GenericDialog
> functionality.
>   >
>   > Regards
>   >
>   > Herbie
>   >
>   > :::::::::::::::::::::::::::::::::::::::::::
>   > Am 24.09.19 um 18:21 schrieb Curtis Rueden:
>   >> Hi,
>   >>
>   >>> I would also like to have more functionality for additional buttons
>   >>
>   >> ImageJ2-style Command plugins support any number of extra buttons with
>   >> syntax:
>   >>
>   >>    import org.scijava.widget.Button;
>   >>    ...
>   >>    @Plugin(type = Command.class)
>   >>    public class MyCommandWithHelp {
>   >>    ...
>   >>    @Parameter(label = "Help", callback = "help")
>   >>    private Button helpButton;
>   >>    ...
>   >>    private void help() {
>   >>      System.out.println("Help button pressed.");
>   >>    }
>   >>    ...
>   >>    public void run() {
>   >>      System.out.println("Command executing");
>   >>      ...
>   >>    }
>   >>    ...
>   >>
>   >> See here for a demo of SciJava parameters in action (though not a lot of
>   >> extra buttons):
>   >>
> https://github.com/imagej/tutorials/blob/27d059117b3bfd1c73d8300f3193db11f6aebb9d/maven-projects/widget-demo/src/main/java/WidgetDemo.java#L244-L245
>   >>
>   >> Regards,
>   >> Curtis
>   >>
>   >> --
>   >> Curtis Rueden
>   >> Software architect, LOCI/Eliceiri lab - https://loci.wisc.edu/software
>   >> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>   >> Have you tried the Image.sc Forum? https://forum.image.sc/
>   >>
>   >>
>   >>
>   >> On Tue, Sep 24, 2019 at 6:05 PM Michael Schmid <[hidden email]>
>   >> wrote:
>   >>
>   >>> Hi Philippe,
>   >>>
>   >>> yes, I would also like to have more functionality for additional
>   >>> buttons, and I am sometimes "misusing" the "No" button for such
> purposes.
>   >>>
>   >>> In your sample code, after gd.showDialog() I think that the code will
>   >>> never again be able to react to the dialog, even if the dialog remains
>   >>> on the screen?
>   >>>
>   >>> So I think we need some callback, using the DialogListener and/or
>   >>> ActionListener interface.
>   >>>
>   >>> So my dream would be a GenericDialog method
>   >>>     Button[] addBottomButtons(String[] buttonLabels)
>   >>> which adds one or more buttons at the position where usually the 'no'
>   >>> button would appear.
>   >>> Or, alternatively,
>   >>>     Button addBottomButton(String buttonLabel)
>   >>> which could be called multiple times (the buttons would go into a
> Vector
>   >>> or ArrayList)
>   >>>
>   >>> Then the user plugin could either use the references to the buttons and
>   >>> register as an ActionListener for them, or it could register as
>   >>> DialogListener and it would get its dialogItemChanged method called
> when
>   >>> the user presses a button while the dialog window is still open.
>   >>>
>   >>> Of course, the same could be done already now by adding a panel
> with the
>   >>> buttons, and registering for each of them as ActionListener, but
> that is
>   >>> more cumbersome, and in many cases one wants the button(s) at the
> bottom.
>   >>>
>   >>> (unfortunately, I can't quickly do the coding now; too much unfinished
>   >>> work on my desk)
>   >>>
>   >>>
>   >>> Michael
>   >>> ________________________________________________________________
>   >>> On 24.09.19 17:09, CARL Philippe (LBP) wrote:
>   >>>> Dear all,
>   >>>> Within the GenericDialog class it is now possible to add an additional
>   >>> button and even customize its name (see
> enableYesNoCancel(java.lang.String
>   >>> yesLabel, java.lang.String noLabel) method).
>   >>>> Nevertheless, it would additionally be interesting to have this custom
>   >>> "No" button being able to launch a method without launching itself the
>   >>> GenericDialog dispose() method, for example for having an "Apply"
> button
>   >>> which would not close the dialog like I illustrated it within the small
>   >>> plugin that can be found here:
>   >>>>        http://punias.free.fr/ImageJ/test/My_Plugin.java
>   >>>> that can be linked with the GenericDialog update try that can be found
>   >>> within:
>   >>>>        http://punias.free.fr/ImageJ/test/GenericDialog.java
>   >>>> Nevertheless I don't know how I could define the method I would
> like to
>   >>> launch from "outside" the GenericDialog class.
>   >>>> I thank you very much in advance for your lighting on this.
>   >>>> My best regards
>   >>>> Philippe
>   >>>>
>   >>>> Philippe CARL
>   >>>> Laboratoire de Bioimagerie et Pathologies
>   >>>> UMR 7021 CNRS - Université de Strasbourg
>   >>>> Faculté de Pharmacie
>   >>>> 74 route du Rhin
>   >>>> 67401 ILLKIRCH
>   >>>> Tel : +33(0)3 68 85 41 84
>   >>>>
>   >>>> --
>   >>>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>   >>>>
>   >>>
>   >>> --
>   >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>   >>>
>   >>
>   >> --
>   >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>   >>
>   >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html