"No" button within GenericDialog class feature update

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

"No" button within GenericDialog class feature update

CARL Philippe (LBP)
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Michael Schmid-3
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Curtis Rueden-2
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Herbie
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Michael Schmid-3
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Herbie
In reply to this post by Herbie
Dear Michael,

I think I understand your suggestion but my concern was more that any
changes in this direction shouldn't break the existing functionality of
the GenericDialog. In other words, if additional buttons are *not* used
(pushed), macro recordability should be preserved.

If we start breaking the recording feature, we give up a valuable tool
for very many users who are no coding experts.

Best

Herbie

::::::::::::::::::::::::::::::::::::::::::::
Am 24.09.19 um 19:25 schrieb Michael Schmid:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

CARL Philippe (LBP)
In reply to this post by Michael Schmid-3
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Michael Schmid-3
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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

CARL Philippe (LBP)
In reply to this post by Michael Schmid-3
Dear Michael,
I had missed to answer your following question:

> 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?

The code is reacting as I expected it.
Indeed, if you look at the line 1388 of the modified version of the GenericDialog code I had put under :
        http://punias.free.fr/ImageJ/test/GenericDialog.java
I had written:
        if (source==okay || source==cancel | source==no) {
                wasCanceled = source==cancel;
                wasOKed = source==okay;
                if(source==no && noDispose) {
                        wasOKed = false;
                        IJ.log("not disposing the window");
                        ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
                        impTest.show();
                } else
                dispose();
        }
And the following written code:
                        IJ.log("not disposing the window");
                        ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
                        impTest.show();
can be run several times as I wanted it.
Nevertheless, the "wished launched code" has to be written within the GenericDialog class which makes it non suitable.
Thus, what would just be needed is to have the possibility to pass the pointer to a void defined outside the GenericDialog class.
And I'm saying this, since I have already seen such tricky coding in C within the Levmar library (when you are defining the equation to be fitted as well as its jacobians):
        http://users.ics.forth.gr/~lourakis/levmar/
But such advanced coding is way beyond my coding level either in C or in Java...
kindest regards,
Philippe

----- Mail original -----
De: "Michael Schmid" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Mardi 24 Septembre 2019 18:02:47
Objet: Re: "No" button within GenericDialog class feature update

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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Michael Schmid-3
Hi Philippe,

the idea with a DialogListener or the ActionPerformed method called back
by the buttons is exactly for avoiding to write the commands into the
GenericDialog class (which, obviously, is not a solution); these
commands would then go into the DialogItemChanged method of your plugin.

So what exactly do you want to do with the button? Maybe it can be done
already with the current GenericDialog, if your plugin implements the
DialogListner interface...


Michael
________________________________________________________________

On 25.09.19 11:05, CARL Philippe (LBP) wrote:

> Dear Michael,
> I had missed to answer your following question:
>
>> 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?
>
> The code is reacting as I expected it.
> Indeed, if you look at the line 1388 of the modified version of the GenericDialog code I had put under :
> http://punias.free.fr/ImageJ/test/GenericDialog.java
> I had written:
> if (source==okay || source==cancel | source==no) {
> wasCanceled = source==cancel;
> wasOKed = source==okay;
> if(source==no && noDispose) {
> wasOKed = false;
> IJ.log("not disposing the window");
> ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
> impTest.show();
> } else
> dispose();
> }
> And the following written code:
> IJ.log("not disposing the window");
> ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
> impTest.show();
> can be run several times as I wanted it.
> Nevertheless, the "wished launched code" has to be written within the GenericDialog class which makes it non suitable.
> Thus, what would just be needed is to have the possibility to pass the pointer to a void defined outside the GenericDialog class.
> And I'm saying this, since I have already seen such tricky coding in C within the Levmar library (when you are defining the equation to be fitted as well as its jacobians):
> http://users.ics.forth.gr/~lourakis/levmar/
> But such advanced coding is way beyond my coding level either in C or in Java...
> kindest regards,
> Philippe
>
> ----- Mail original -----
> De: "Michael Schmid" <[hidden email]>
> À: "imagej" <[hidden email]>
> Envoyé: Mardi 24 Septembre 2019 18:02:47
> Objet: Re: "No" button within GenericDialog class feature update
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

CARL Philippe (LBP)
Dear Michael,
I will inspire from your Plot>>More>>Contents_style... code and will more than probably be able to solve my issue.
Thanks a lot for your replies and have a nice day.
Kindest regards,
Philippe

----- Mail original -----
De: "Michael Schmid" <[hidden email]>
À: "imagej" <[hidden email]>
Envoyé: Mercredi 25 Septembre 2019 22:53:46
Objet: Re: "No" button within GenericDialog class feature update

Hi Philippe,

the idea with a DialogListener or the ActionPerformed method called back
by the buttons is exactly for avoiding to write the commands into the
GenericDialog class (which, obviously, is not a solution); these
commands would then go into the DialogItemChanged method of your plugin.

So what exactly do you want to do with the button? Maybe it can be done
already with the current GenericDialog, if your plugin implements the
DialogListner interface...


Michael
________________________________________________________________

On 25.09.19 11:05, CARL Philippe (LBP) wrote:

> Dear Michael,
> I had missed to answer your following question:
>
>> 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?
>
> The code is reacting as I expected it.
> Indeed, if you look at the line 1388 of the modified version of the GenericDialog code I had put under :
> http://punias.free.fr/ImageJ/test/GenericDialog.java
> I had written:
> if (source==okay || source==cancel | source==no) {
> wasCanceled = source==cancel;
> wasOKed = source==okay;
> if(source==no && noDispose) {
> wasOKed = false;
> IJ.log("not disposing the window");
> ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
> impTest.show();
> } else
> dispose();
> }
> And the following written code:
> IJ.log("not disposing the window");
> ImagePlus impTest = IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
> impTest.show();
> can be run several times as I wanted it.
> Nevertheless, the "wished launched code" has to be written within the GenericDialog class which makes it non suitable.
> Thus, what would just be needed is to have the possibility to pass the pointer to a void defined outside the GenericDialog class.
> And I'm saying this, since I have already seen such tricky coding in C within the Levmar library (when you are defining the equation to be fitted as well as its jacobians):
> http://users.ics.forth.gr/~lourakis/levmar/
> But such advanced coding is way beyond my coding level either in C or in Java...
> kindest regards,
> Philippe
>
> ----- Mail original -----
> De: "Michael Schmid" <[hidden email]>
> À: "imagej" <[hidden email]>
> Envoyé: Mardi 24 Septembre 2019 18:02:47
> Objet: Re: "No" button within GenericDialog class feature update
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Fred Damen
In reply to this post by Michael Schmid-3
Greetings,

On a side note, the dialogItemChanged method returns a boolean which controls
the enabled / disabled state of the "OK" button.  I use dialogItemChanged in
part to validate the current field settings and prevent the user from making a
bogus request. The problem is that the default state of the "OK" button is
enabled.  I assume that I could go under the hood and disable the "OK" button
myself before showDialog, albeit, if the form was filled out acceptably the
user would have to change something to get dialogItemChanged; what I would
really like is to be able to have the dialogItemChanged method called, and
"OK" button state determined, before displaying the "OK" button for the first
time; this would allow the 'is the request valid' code in one place.

Thanks for listening,

Fred

On Wed, September 25, 2019 3:53 pm, Michael Schmid wrote:

> Hi Philippe,
>
> the idea with a DialogListener or the ActionPerformed method called back
> by the buttons is exactly for avoiding to write the commands into the
> GenericDialog class (which, obviously, is not a solution); these
> commands would then go into the DialogItemChanged method of your plugin.
>
> So what exactly do you want to do with the button? Maybe it can be done
> already with the current GenericDialog, if your plugin implements the
> DialogListner interface...
>
>
> Michael
> ________________________________________________________________
>
> On 25.09.19 11:05, CARL Philippe (LBP) wrote:
>> Dear Michael,
>> I had missed to answer your following question:
>>
>>> 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?
>>
>> The code is reacting as I expected it.
>> Indeed, if you look at the line 1388 of the modified version of the
>> GenericDialog code I had put under :
>> http://punias.free.fr/ImageJ/test/GenericDialog.java
>> I had written:
>> if (source==okay || source==cancel | source==no) {
>> wasCanceled = source==cancel;
>> wasOKed = source==okay;
>> if(source==no && noDispose) {
>> wasOKed = false;
>> IJ.log("not disposing the window");
>> ImagePlus impTest =
>> IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
>> impTest.show();
>> } else
>> dispose();
>> }
>> And the following written code:
>> IJ.log("not disposing the window");
>> ImagePlus impTest =
>> IJ.openImage("http://wsr.imagej.net/images/AuPbSn40.jpg");
>> impTest.show();
>> can be run several times as I wanted it.
>> Nevertheless, the "wished launched code" has to be written within the
>> GenericDialog class which makes it non suitable.
>> Thus, what would just be needed is to have the possibility to pass the
>> pointer to a void defined outside the GenericDialog class.
>> And I'm saying this, since I have already seen such tricky coding in C
>> within the Levmar library (when you are defining the equation to be fitted
>> as well as its jacobians):
>> http://users.ics.forth.gr/~lourakis/levmar/
>> But such advanced coding is way beyond my coding level either in C or in
>> Java...
>> kindest regards,
>> Philippe
>>
>> ----- Mail original -----
>> De: "Michael Schmid" <[hidden email]>
>> À: "imagej" <[hidden email]>
>> Envoyé: Mardi 24 Septembre 2019 18:02:47
>> Objet: Re: "No" button within GenericDialog class feature update
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: "No" button within GenericDialog class feature update

Michael Schmid-3
Hi Fred,

yes, the "OK" button is always enabled at the start, but wouldn't it be
confusing for the user to display a dialog with a disabled OK button?
You would get a disabled OK button only if the default parameters are
invalid (as determined by the dialogItemChanged method), so why suggest
invalid parameters to the user?
Usually, the parameters are taken from the last successful invocation of
the dialog, and there they must have been valid (otherwise there would
have been no way to press ok), or they are predefined parameters (where
it is the programmer's task to suggest reasonable values).
If the now-invalid parameters are from the last invocation (where they
were valid, e.g. because it was a larger image where these coordinates
had been ok), why not correct  these values, to have default parameters
that are valid for the current image? And if there is for some reasons
no way to enter valid parameters (e.g. if you have to enter three
different integer x coordinates of a 1x1 pixel image), there should be
an error message instead of the dialog.

I am not sure whether modifying the GenericDialog to call
dialogItemChanged before the dialog is displayed would be compatible
with all existing plugins, which do not expect such a behavior. The
documentation of the GenericDialog.addDialogListener method specifies
exactly when the DialogListeners get called, and user plugins might rely
on this.


Best,

Michael
________________________________________________________________

On 26.09.19 20:09, Fred Damen wrote:

> Greetings,
>
> On a side note, the dialogItemChanged method returns a boolean which controls
> the enabled / disabled state of the "OK" button.  I use dialogItemChanged in
> part to validate the current field settings and prevent the user from making a
> bogus request. The problem is that the default state of the "OK" button is
> enabled.  I assume that I could go under the hood and disable the "OK" button
> myself before showDialog, albeit, if the form was filled out acceptably the
> user would have to change something to get dialogItemChanged; what I would
> really like is to be able to have the dialogItemChanged method called, and
> "OK" button state determined, before displaying the "OK" button for the first
> time; this would allow the 'is the request valid' code in one place.
>
> Thanks for listening,
>
> Fred

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