Need more ways to collect numeric input

[lnyng]

It would be nice if there is an interface for the commands to generate more specific ways to collect numeric inputs from the users.

Right now the default way is a text box with the up\down arrows on the right. How to modify the step of the up/down arrows? Can we tell the ui to use slider instead?

[ctrueden]

You can modify the step using the stepSize attribute of @Parameter. You can use a slider using style = NumberWidget.SLIDER_STYLE. See the WidgetDemo tutorial for more possibilities.

[imagejan]

@ctrueden Is this supposed to work from within scripts as well? I just tried style="SLIDER_STYLE", stepSize=10 in a Groovy script, but it was ignored.

[ctrueden]

@imagejan Yes, it works from scripts, but you have to use the string literal rather than the constant. The script parser does not interpret constants. So write style="slider" and it will work. (If you look at the value of NumberWidget.SLIDER_STYLE you'll see that it is "slider".)

[ctrueden]

Perhaps in the future, the script parser will interpret constants and other goodies, by leaning on JSON or Groovy or JavaScript or similar. See scijava/scijava-common#156 for some discussion along those lines.

[imagejan]

Wow, the following Groovy snippet gives me an empty dialog without the possibility of closing it, thereby blocking Fiji completely:

// @int(label="Number", style="slider", value="1") a

print(a);

[ctrueden]

@imagejan Wow, that's horrible. I am able to reproduce here as well. (OS X El Capitan, Java 1.7.0_80 and 1.8.0_66 both exhibit the issue.)

A backtrace on the CLI shows:

"AWT-EventQueue-0" #15 prio=6 os_prio=31 tid=0x0000000100eb5000 nid=0xf303 runnable [0x0000700001ffb000]
   java.lang.Thread.State: RUNNABLE
    at sun.java2d.pipe.PixelToParallelogramConverter.drawGeneralLine(PixelToParallelogramConverter.java:205)
    at sun.java2d.pipe.PixelToParallelogramConverter.drawLine(PixelToParallelogramConverter.java:80)
    at sun.java2d.SunGraphics2D.drawLine(SunGraphics2D.java:2234)
    at javax.swing.plaf.basic.BasicSliderUI.paintMinorTickForHorizSlider(BasicSliderUI.java:1106)
    at javax.swing.plaf.basic.BasicSliderUI.paintTicks(BasicSliderUI.java:1021)
    at com.apple.laf.AquaSliderUI.paintTicks(AquaSliderUI.java:226)
    at com.apple.laf.AquaSliderUI.paint(AquaSliderUI.java:156)
    at javax.swing.plaf.ComponentUI.update(ComponentUI.java:161)
    at javax.swing.JComponent.paintComponent(JComponent.java:780)
    at javax.swing.JComponent.paint(JComponent.java:1056)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
    - locked <0x00000006befcae20> (a java.awt.Component$AWTTreeLock)
    at javax.swing.JComponent.paint(JComponent.java:1065)
    at javax.swing.JComponent.paintChildren(JComponent.java:889)
...

The problem is not unique to Groovy either—I tried BeanShell and IJ1 Macro and they both exhibit the problem, so it probably happens for all script languages.

[ctrueden]

Writing style="scroll bar" works (although scroll bars are broken on El Capitan). But at least it doesn't freeze. So it seems to be something specific to the JSlider widget?

[imagejan]

@ctrueden Thanks for the quick diagnosis. Yes, style="scroll bar" works, but stepSize=10 (or stepSize="10") is being ignored in my trials with scripts (Groovy, Python, etc.).

[ctrueden]

I briefly tried to reproduce this hang with the following BeanShell script:

import javax.swing.*;
f = new JFrame("Test");
slider = new JSlider(50, 100, 50);
slider.setMajorTickSpacing((100 - 50) / 4);
slider.setMinorTickSpacing(1);
slider.setPaintLabels(true);
slider.setPaintTicks(true);
slider.setToolTipText("Why hello there");
f.getContentPane().add(slider);
f.pack();
f.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
f.setVisible(true);

But it is not triggered by the above code.

[lnyng]

@imagejan @ctrueden I find that the bug will not occur when you have max and min set.

// @int(label="number", max="10", min="0", value="1", style="slider") a
print(a)

I tested it with Groovy, Javascript, IJ1Macro, and all work well.

[imagejan]

@LeonYang5114 👍 that makes sense! So we should just make sure to have some default min and max in the code, or to complain if they weren't set.

Can you confirm that the stepSize is being ignored, though?

[lnyng]

@ctrueden The bug seems to be a little more than just painting too many ticks. The problem comes from javax.swing.plaf.basic.BasicSliderUI (Line#1004 to Line#1010)

            if ( slider.getMinorTickSpacing() > 0 ) {
                while ( value <= slider.getMaximum() ) {
                    xPos = xPositionForValue( value );
                    paintMinorTickForHorizSlider( g, tickBounds, xPos );
                    value += slider.getMinorTickSpacing();
                }
            }

Here the class tries to paint the ticks from left to right until the tick represents a value greater than the maximum value allowed. However, since slider.getMaximum() returns Integer.MAX_VALUE by default, the while loop never ends!

It seems that we need to change the default max/min somehow to fix this bug, in addition to changing the minor tick size.

@imagejan For the problem of ignoring the stepSize, I will look into that after this bug is fixed.

[ctrueden]

@LeonYang5114 The original idea was not to allow slider or scroll bar at all if min/max wasn't set. I.e.: just ignore the style in those cases. But we might want to issue a warning then, since otherwise the behavior is rather mysterious.

I really have no idea what a good "default" would be for min/max when they aren't specified. It is completely dependent on the individual scenario. @imagejan Any suggestions?