Widget grouping

[tischi]

Making it possible to group IJ2 plugin widgets, e.g. horizontally or in tabs, would be great in order to structure the UI in case of many inputs.
See also:
http://forum.imagej.net/t/any-control-over-parameterized-input-field-position-layout/1554/5

[imagejan]

For choices, there is radioButtonHorizontal already:

#@ String (choices={"a", "b", "c"}, style="radioButtonHorizontal") myChoice

(I would also love to see multiple-select (#260) creating a list of checkboxes in this context.)

---

How would you imagine a possible syntax to create horizontal or tab groups? Something like this:

#@ Boolean (style="group-horizontal", group="first") a
#@ String (style="group-horizontal", group="first") b
#@ Boolean (style="group-horizontal", group="second") c
#@ String (style="group-horizontal", group="second") d
#@ String (style="group-tab", group="other") e

?

How would you decide how to render things if not all parameters have group annotations? All unannotated parameters go into the "main" dialog?

---

Another option (at least in scripts) would be to define tab groups in a new line with a dedicated script directive, but I don't know how the same would be nicely achievable in Java plugins then...

[tischi]

Your syntax with (style="group-horizontal", group="first") looks sensible to me.

Horizontal grouping

I guess one could still keep the logic that the parameters appear vertically in the same order as in the code (for groups I would take the first appearance of the respective group as the order). For example:

#@ Boolean (style="group-horizontal", group="first") a
#@ Boolean (style="group-horizontal", group="second") c
#@ String e
#@ String (style="group-horizontal", group="second") d
#@ String (style="group-horizontal", group="first") b

Would appear in this order

a    b
c    d
e

Tabs

I think, for starters, maybe it would be good to just implement first the horizontal grouping idea and leave out the tab idea for now. What do you think?

[imagejan]

I think, for starters, maybe it would be good to just implement first the horizontal grouping idea and leave out the tab idea for now. What do you think?

Seems sensible.

---

So here's a (likely incomplete) list of things to be done:

• add a group attribute to the Parameter interface:

  String group() default "";
  

• add constant String HORIZONTAL_GROUP_STYLE = "group-horizontal" to InputWidget (or would somewhere else be more suitable?)

• implement the actual grouping and layout in scijava-ui-swing/imagej-legacy

@ctrueden, @bnorthan, @nicost Does that sound reasonable?

[hadim]

Just checking here if any progress has been made on that front?

[ctrueden]

Sorry @hadim, I have not worked on it yet. I will be working on the next major version of SciJava Common over the summer.

[skalarproduktraum]

Hi everyone, sorry for being late to the party, @imagejan has just pointed me to this. I was in need for such functionality for sciview, here's what this looks like:

The way this is implemented is adding a group: attribute to @Parameter's style (thanks again to @imagejan for pointing style out to me, I had (ab)used description before, style is a much better place for this). My ideal solution would have been to use Attr for that, but unfortunately, DefaultMutableModuleItem does not have access to attrs(), while CommandModuleItem does and I did not find an easy solutinon or workaround for this.

Now we need this only in the inspector panel so far, so I have created a new input harvester, called the SwingGroupingInputHarvester. The only changes this one has compared to the regular SwingInputHarvester is that it groups the inputs by the above group: attribute, and creates a collapsible JPanel for each of the members.

As said I didn't know about this discussion here, I'm happy to PR this after I2K 👍

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/access-to-imagej2-input-harvester-generated-elements/49338/5

[NicoKiaru]

Can't wait! Where's the PR @skalarproduktraum ;-) ?

[karlduderstadt]

@skalarproduktraum This is a really cool idea. My dialogs are in desperate need of groups. I guess in your implementation you directly build the panel with the SwingGroupingInputHarvester. I went ahead and tried to make a draft of this to integrate into scijava-ui-swing, which is currently on a branch of my fork - https://github.com/karlduderstadt/scijava-ui-swing/tree/group_dialog_inputs actually all changes are currently in one commit - karlduderstadt/scijava-ui-swing@1fa38cd

This lead to several questions about how best to implement it. Seemed like the best option was to change the SwingInputHarvester to detect the group style and in that case use a new class for building the input panel, which I called SwingGroupedInputPanel (https://github.com/karlduderstadt/scijava-ui-swing/blob/group_dialog_inputs/src/main/java/org/scijava/ui/swing/widget/SwingGroupedInputPanel.java).

I am having trouble testing it though because in legacy UI mode, which I was using, I guess the SwingInputHarvester is not used ? Or is called from somewhere else? I am pretty confused about this. I don't have more time to investigate now.

[ctrueden]

in legacy UI mode, which I was using, I guess the SwingInputHarvester is not used ?

It is still used, because LegacyUI implements the SwingUI interface, so the legacy user interface is still treated as a Swing one, for the purpose of things like the SwingInputHarvester.

Seemed like the best option was to change the SwingInputHarvester to detect the group style and in that case use a new class for building the input panel, which I called SwingGroupedInputPanel

My plan years ago for adding group support was to add a group field to ModuleItem, and also to the Parameter annotation interface. Then improve the standard SwingInputPanel et al. to check for groups and respect them. Needing a second InputPanel implementation would be unfortunate, although I'm open to it if you really don't see any simpler way.

[karlduderstadt]

Thanks for the helpful feedback! Aww that makes sense. I assumed it was something like that since clearly the SwingInputHarvester is used.

Adding a group field to ModuleItem and a Parameter annotation sounds like a better plan. I agree having an additional panel is not ideal and putting SwingInputPanels inside SwingInputPanels doesn't really seem to make a lot of sense. I will work on the strategy you suggested, adding getWidgetGroup() to ModuleItem etc., improving SwingInputPanel and see how it goes.

I do like the collapsible group labels that @skalarproduktraum developed. It might actually be nice if it was possible to specify if groups should be expanded or collapsed in commands by default and if user changes were persisted when running a command a couple times. I was thinking this could be achieved by adding group labels as boolean parameters and then setting something like visibility = ItemVisibility.GROUPNAME. But the mechanics seem a bit awkward. Is there a way group status (expanded or collapsed) can be persisted without having to add a group label parameter?

I am assuming in your proposal, the group name is only specified in the Parameter annotations of group members, and there is no separate group title/label parameter needed.

[ctrueden]

It might actually be nice if it was possible to specify if groups should be expanded or collapsed in commands by default

Good idea. One solution that comes to mind, which would be relatively extensible, would be support some hints in brackets after the group name. So you could do e.g.:

@Parameter(group = "Basic configuration", label = "Number of ducks")
private int duckCount = 1;

@Parameter(group = "Basic configuration", label = "Time of next feeding")
private Date nextFeeding = new Date();

@Parameter(group = "Advanced options[collapsed]", label = "Advanced duck typing")
private boolean advancedDuckTyping = true;

@Parameter(group = "Advanced options", label = "Starvation threshold")
private int starvationThreshold = 6;

Where [collapsed] is a shorthand for [collapsed=true]. Such comma-separated key=value pairs can be parsed easily using Parsington. Of course, the code could do something inconsistent like collapsed=true for one parameter and collapsed=false for another, but we could just have a "last setting wins" rule, which would be easy to code.

Or here's another idea:

@ParameterGroup
private String basic = "Basic configuration";

@ParameterGroup(expanded = false)
private String advanced = "Advanced options";

@Parameter(group = "basic", label = "Number of ducks")
private int duckCount = 1;

@Parameter(group = "basic", label = "Time of next feeding")
private Date nextFeeding = new Date();

@Parameter(group = "advanced", label = "Advanced duck typing")
private boolean advancedDuckTyping = true;

@Parameter(group = "advanced", label = "Starvation threshold")
private int starvationThreshold = 6;

Any better ideas?

[karlduderstadt]

I really like the second idea. That appears to satisfy the key requirements. Then we would have full control over the default state. Also, having a separate ParameterGroup annotation seems to make things very clear. As a fall back, if no ParameterGroup is specified but there is a group specified in other input annotations we could still create the group using the name provided. I will see if I can add it.

Just one question for now, would the expanded setting persist based on user changes?

If, for example, I run the command and expand all collapsed groups, will they remain expanded the next time I run the command. I know variable values persist, but I guess these options provided within the parameter don't. I suppose this is not an absolute requirement, but it would be nice.

[ctrueden]

If, for example, I run the command and expand all collapsed groups, will they remain expanded the next time I run the command. I know variable values persist, but I guess these options provided within the parameter don't. I suppose this is not an absolute requirement, but it would be nice.

It will not happen automatically. But you could code the groups logic to do it. You can use the PrefService to persist whatever information you want. Happy to help with this part after we have an initial version working.