This converter allows to get a ResultsTable by its title string. In addition, the populateInputCandidates() method allows to get a list of open results tables, e.g. to generate a choice dropdown in ObjectWidget.
Since we're using ImageJ1 classes directly, we need to add the new converter class to the exceptions in ImageJ1EncapsulationTest.
It would be nice to extend the functionality to also allow loading ResultsTables from files, using the static ResultsTable.open(String path) method (possibly delegating to a new FileToResultsTableConverter). I'll leave this to a future pull request.
The current implementation of ObjectWidget and ObjectService#getName() returns the ResultsTable's toString() value, resulting in a rather cryptic identifier in the dropdown choice:
#@ ResultsTable (autoFill = false) rt
We could create a custom widget for ResultsTable, but I'd prefer using ObjectWidget to keep everything concise (and staying with a converter has the added benefit that #@ parameters are callable from CLI/macros right away). Maybe we can improve ObjectService somehow to be extensible via a (new) NameProvider plugin mechanism, but I'm not sure if this would be overdoing it? @ctrueden do you have some opinion/advice here?
Tests for the new converter are currently missing.
This converter allows to get a
ResultsTableby its title string. In addition, thepopulateInputCandidates()method allows to get a list of open results tables, e.g. to generate a choice dropdown inObjectWidget.Since we're using ImageJ1 classes directly, we need to add the new converter class to the exceptions in
ImageJ1EncapsulationTest.See also this forum discussion.
To be discussed:
ResultsTables from files, using the staticResultsTable.open(String path)method (possibly delegating to a newFileToResultsTableConverter). I'll leave this to a future pull request.The current implementation of
ObjectWidgetandObjectService#getName()returns theResultsTable'stoString()value, resulting in a rather cryptic identifier in the dropdown choice:We could create a custom widget for
ResultsTable, but I'd prefer usingObjectWidgetto keep everything concise (and staying with a converter has the added benefit that#@parameters are callable from CLI/macros right away). Maybe we can improveObjectServicesomehow to be extensible via a (new)NameProviderplugin mechanism, but I'm not sure if this would be overdoing it? @ctrueden do you have some opinion/advice here?