GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Add Multiple Select parameter · Issue #260 · scijava/scijava-common

Add Multiple Select parameter #260

New issue
Copy link
New issue
Copy link
Open
Open
Add Multiple Select parameter#260
Copy link
Labels
unscheduled
Milestone
unscheduled

Description

@imagejan
imagejan
opened on Mar 28, 2017
Issue body actions

It would be useful to have a Multiple Select parameter in addition to the single choice that is possible with String parameters and the choices annotation.

Maybe this could be implemented as a new SelectionWidget with two styles:

  • a list of checkboxes
  • a textbox list with the possibility to select multiple lines

What do you think?

Reacted by John Bogovic

Activity

  1. ctrueden commented on Mar 29, 2017

    @ctrueden
    ctrueden
    on Mar 29, 2017
    Member
    More actions

    @imagejan What would you suggest for the underlying data structure? I.e.: the actual type of the parameter?

  2. imagejan commented on Mar 29, 2017

    @imagejan
    imagejan
    on Mar 29, 2017
    MemberAuthor
    More actions

    Maybe String[] or List<String>?

  3. ctrueden
    added a commit that references this issue on Apr 11, 2017

    WIP: Add a multi-select widget

    513950f
  4. ctrueden commented on Apr 11, 2017

    @ctrueden
    ctrueden
    on Apr 11, 2017
    Member
    More actions

    I took a look, but this is a bit tricky type-wise.

    The ModuleItem interface defines the following API:

    /** Gets the list of possible values. */
    List<T> getChoices();
    
    /** Gets the item's current value with respect to the given module. */
    T getValue(Module module);
    
    /** Sets the item's current value with respect to the given module. */
    void setValue(Module module, T value);

    Suppose we have a parameter like this:

    @Parameter(choices = {"Alice", "Bob", "Charlie"})
    List<String> names;
    

    The type T of the parameter is List<String>, which makes sense for getValue and setValue, but getChoices in this case returns List<List<T>> so we would have to—I guess—return each name in its own singleton list. I do not believe such a conversion currently happens. And it is a bit misleading since the idea of "choices" now changes: it does not imply the value must equal one and only one of the choices given anymore.

    But some hackish solution still seems feasible on the surface, so I started trying to implement something. But it does not work yet.

    And here is the Groovy script I used for testing:

    // @String(choices = {"quick", "brown", "fox"}) single
    // @java.util.List(choices = {"the", "lazy", "dog"}) multiple
    println("single = " + single)
    println("multiple = " + multiple)
  5. imagejan commented on Apr 12, 2017

    @imagejan
    imagejan
    on Apr 12, 2017
    MemberAuthor
    More actions

    But it does not work yet.

    Right, I get:

    java.lang.NullPointerException
    	at org.scijava.widget.DefaultWidgetModel.getChoices(DefaultWidgetModel.java:234)
    

    As far as I get it, choicesList.get(i) seems to be null here:

    scijava-common/src/main/java/org/scijava/widget/DefaultWidgetModel.java

    Line 234 in f7457f0

    choices[i] = choicesList.get(i).toString();

    ... so item.getChoices() seems to return a list of null values ?!

    Reacted by John Bogovic
  6. ctrueden commented on Apr 12, 2017

    @ctrueden
    ctrueden
    on Apr 12, 2017
    Member
    More actions

    so item.getChoices() seems to return a list of null values

    Yep.

    Upon further thought, I think changing the implicit contract for getChoices() is not the way to go here. That method is supposed to return a list of constrained values for the item, and I don't want to pervert that here.

    Instead, we should expand the ModuleItem API to add new method(s) with something like getPossibleElements() that returns, I dunno, I guess just List<Object>, since there is no way to decompose the T here. Alternately we could make a new ModuleListItem<E> extends ModuleItem<List<E>> although that comes with its own challenges.

    This project is, unfortunately, too involved for me to tackle any time soon. It requires some experimentation, together with careful thought about the API and implications.

    Reacted by John Bogovic
  7. ctrueden
    added this to the unscheduled milestone on Apr 12, 2017
  8. ctrueden
    added
    unscheduled
    on Oct 3, 2018
  9. imagesc-bot commented on Oct 6, 2020

    @imagesc-bot
    imagesc-bot
    on Oct 6, 2020
    More actions

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

    https://forum.image.sc/t/how-to-customize-override-scijava-ui/43642/4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    unscheduled

    Type

    No type

    Projects

    No projects

      Milestone

      • unscheduledNo due date

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.