You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the vast majority of commands in imagej-plugins-commands have the no-legacy flag, and the imagej-legacy logic disables such commands. So all these "ImageJ2 command rewrites" are discarded in favor of original ImageJ commands, and thus not available in napari-imagej. But napari-imagej does not support running original ImageJ commands. We need to change this.
There are five distinct classes of commands worth articulating individually:
SciJava script wrappers for original ImageJ commands. We started working on creating these, but they don't exist yet. See Wrap headless-friendly ImageJ 1.x commands as parameterized SciJava scripts #264. Once these exist, they can be shown in the search results, at least while headless, since they will enable the majority of original ImageJ commands to work headless.
ImageJ2 no-legacy commands. These are the commands relevant to this issue: those declaring the no-legacy property. These ought to be accessible in both the ImageJ legacy UI and napari-imagej, but we need to clearly delineate them in the search results; see below.
SciJava modules with new functionality. These are any module without the no-legacy property (e.g. "System Information"). They appear now in search results, but there are surprisingly few. Probably no changes are needed here.
ImageJ Ops. These are SciJava modules, but handled specially, returned in a separate search category. Unfortunately, napari-imagej doesn't handle them well as of this writing. But they are outside the scope of imagej-legacy-related work described by this issue.
The work to improve this situation on the imagej-legacy side is as follows:
Do not suppress no-legacy commands from the ModuleService. But do not add them to the ImageJ menu system, either. They need to be accessible from the search bar only.
Make original ImageJ commands appear as their own category in search results. Get rid of LegacyCommand (again), since it's considered harmful. Original ImageJ commands are not SciJava modules, and should not be treated as such.
The script wrappers (2) and no-legacy commands (3) should perhaps each be unchecked by default in search results within the ImageJ legacy UI. But both enabled by default in napari-imagej search. Investigate the best way to achieve this.
The text was updated successfully, but these errors were encountered:
Right now, the vast majority of commands in
imagej-plugins-commands
have theno-legacy
flag, and theimagej-legacy
logic disables such commands. So all these "ImageJ2 command rewrites" are discarded in favor of original ImageJ commands, and thus not available in napari-imagej. But napari-imagej does not support running original ImageJ commands. We need to change this.There are five distinct classes of commands worth articulating individually:
no-legacy
property. These ought to be accessible in both the ImageJ legacy UI and napari-imagej, but we need to clearly delineate them in the search results; see below.no-legacy
property (e.g. "System Information"). They appear now in search results, but there are surprisingly few. Probably no changes are needed here.The work to improve this situation on the imagej-legacy side is as follows:
no-legacy
commands from theModuleService
. But do not add them to the ImageJ menu system, either. They need to be accessible from the search bar only.LegacyCommand
(again), since it's considered harmful. Original ImageJ commands are not SciJava modules, and should not be treated as such.#@script
directive (Implement #@script directive with most @Plugin attributes scijava/scijava-common#294), so that properties can be attached to the script wrappers.no-legacy
commands (3) should perhaps each be unchecked by default in search results within the ImageJ legacy UI. But both enabled by default in napari-imagej search. Investigate the best way to achieve this.The text was updated successfully, but these errors were encountered: