MacroPreprocessor: resolve Button type inputs #262
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When calling a command from a macro, we usually don't want to show a UI dialog. If the called command contains inputs of type Button, we resolve these without setting them, as we assume that buttons and their callbacks provide some interactivity that is not required when running from macro. See #239 for some discussion.
Member
Author
|
See #239 (comment), thanks @biovoxxel for testing! @hinerm @ctrueden is there any chance we can get this merged and released soon? |
tferr
added a commit
to tferr/imagej-legacy
that referenced
this pull request
Feb 19, 2025
This extends imagej#262 further: - Ignore Buttons (these are not recordable in ij.gui.GenericDialog, so this change _should_ not carry breaking changes) - Ignore ColorTables (these are assigned a value parameter but IJM does not know what to do with it) - Ignore inputs tagged w/ ItemVisibility.MESSAGE (as per documentation: this indicated that the item's value is intended as a message to the user rather than an actual parameter to the module execution)
Member
Author
|
With #313 being merged, this can be closed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When calling a command from a macro (with an option string), we usually don't want to show a UI dialog.
If the called command contains inputs of type
org.scijava.widget.Button, we resolve these without setting them, as we assume that buttons and their callbacks provide some interactivity that is not required when running from macro.See the closed PR #239 for some discussion.
I would have liked to respect a
required={false,true}annotation for theButtoninput, but sinceButton extends Optional,isRequired()will always resolve tofalse, see also:https://github.com/scijava/scijava-common/blob/46ca0d04c5c86eeb51f9daa9f130b0d7c8decd65/src/main/java/org/scijava/command/CommandModuleItem.java#L102-L106
I hope that this solution - while being a bit hacky - is less intrusive than #239, but still meets the requirements of the affected projects.
(/cc @frauzufall @NicoKiaru @tischi @romainGuiet @uschmidt83 @tferr)
Note 1: While in full-fledged scripting languages, you can always call
commandService.run("command",false, ...)to avoid the automatic command preprocessing (and hence display of dialogs), this option doesn't exist in an IJ1 macrorun("...")call.Note 2: This pull request still allows commands whose dialog box is nothing else than a button to show a dialog box when invoked from the UI (scenario 1 in this comment by @ctrueden).
Note 3: I tried to add a test for this behavior in 401cb9c, but it's not headless, as it seems this issue only occurs when running from a macro with the UI displayed. In addition, we still cannot distinguish between macro calls with and without option string (
run("Test Command")vs.run("Test Command", ""), see also scijava/scijava-common#317 (comment)).