Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve handling of no-legacy commands #280

Open
ctrueden opened this issue May 26, 2022 · 0 comments
Open

Improve handling of no-legacy commands #280

ctrueden opened this issue May 26, 2022 · 0 comments

Comments

@ctrueden
Copy link
Member

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:

  1. Original ImageJ commands. These only work with GUI. We need to make them a separate section in search results. These will never be accessible from napari-imagej (if you want that, the plan is to provide a button to open the main ImageJ window; see Add a button to pop the ImageJ2 main window when not in headless mode napari-imagej#43).
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  • Complete the SciJava script wrappers for ImageJ commands as described in Wrap headless-friendly ImageJ 1.x commands as parameterized SciJava scripts #264. But make sure these modules are treated specially by the search, also appearing in their own category. This may entail small improvements to the scijava-search infrastructure, so that they can be labeled specially with a property. It may also entail completing the #@script directive (Implement #@script directive with most @Plugin attributes scijava/scijava-common#294), so that properties can be attached to the script wrappers.
  • 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.
ctrueden added a commit to imagej/napari-imagej that referenced this issue Nov 17, 2022
This avoids the issue with FlatLaf not working with the Swing UI.

But we'll need to figure out what to do about imagej/imagej-legacy#280.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant