Missing plugins menu item

fiji
imagej
scripting
menu

#1

I have an ImageJ update site called quantixed which puts a folder in Fiji.app/plugins. It contains a few macros that normally appear under a menu item in Plugins called quantixed (the name of the folder in plugins). This has been working fine until a recent FIJI update (I think) which has removed the menu item. The folder and files are all still there in Fiji.app/plugins and are updating correctly from the update site but are not showing in the menu.

Steps to reproduce

  • A user told me the menu item has disappeared for them and I can reproduce this on a clean FIJI install.
  • An old FIJI install freshly subscribed to quantixed has the item showing correctly in Plugins.
    I subscribed to FiloQuant which has a similar structure to quantixed and this is also missing so I don’t think the problem is specific to my update site.

Is this a known issue since a recent update?
Please feel free to tell me a better way to structure files on my update site.


Newly installed script not showing up in menu
How to find dithering plugin
Plugin scripts no longer appear in plugin menu on mac osx
#2

Hi @quantixed,

thanks for reporting, I can reproduce the issue with an up-to-date Fiji.

I’d consider this a bug, but don’t know (yet) what’s causing it.


As a workaround, you can put all your scripts in a subfolder of ./Fiji.app/scripts/. For example, your folder quantixed should be in:

./Fiji.app/scripts/Plugins/quantixed

to appear in the menu as Plugins > quantixed (mind the exact spelling and capitalization).


#3

Hi @quantixed and @imagejan,

I tried to reproduce the issue with a fresh fiji and activated the quantixed update site. I found the quantixed sub-menu at the very bottom:

Is it possible that the sub-menu is still there and just moved to the end of the menu? Could you please check?

Cheers,
Robert


#4

Hi @haesleinhuepf

That’s the normal location for the sub-menu, but it is definitely missing in my FIJI install. I have only tested on mac though, looks as though it is still working on your OS.


#5

I see. So I can confirm it works on Windows 10 and Fedora linux…

@imagejan: do you by chance know which module/class builds up the ImageJ menu?


#6

There’s some code in imagej-legacy that builds the menu, but I don’t remember which class exactly :frowning:

And scripts in ./plugins/ should actually be recognized by ImageJ 1.x itself. What puzzles me is that scripts in ./scripts/ work just fine, because that’s some code in imagej-legacy.
We’ll have to investigate…

UPDATE: It’s possible that the issue is in LegacyService, as this Groovy script doesn’t list scripts from the ./plugins/ directory (again, tested only on Mac):

#@ LegacyService legacy

scriptlist = legacy.getScriptsAndNonLegacyCommands()

println scriptlist.size() 

scriptlist.each {
	println it.getKey()
}

null

UPDATE2: I don’t think it’s in the imagej-legacy component, and it’s actually not a problem of populating the menus (as script from ./scripts/ work just fine), but rather a problem that scripts are not discovered at startup. Calling scriptService.getScripts() shows that they’re not registered:

#@ ScriptService scripts

println scripts.getScripts().size()

scripts.getScripts().each {
	println it
}

null

#7

Try to rename your plugin to quantixed_.jar


#8

Dear all,
this is a VERY big issue.
After some updates (I don’t know exactly which one) on MacOS users plugins disappear.
I am now facing some users (and myself too) of the campus with this problems:
in few words the plugins (python and ijm all with “_” in the name) plugins are disappeared.
By now I am keeping an old version where plugins are visible.

I have really no idea what is causing that and how to fix it.
Are someone of the community/developers/head of Fiji taking care of it?

THanks a lot,
Emanuele


#9

@ctrueden is currently working on it, see e.g. this commit.

As I mentioned above, you can move all script files from ./plugins into ./scripts/Plugins and they will be discovered just fine.


#10

It gets weirder and weirder.

Indeed, the above linked commit in imagej-legacy avoids the issue. However, I also found that the issue is avoided in SciJava Common as follows:

So the fix is likely to be on the scijava-common side. Still digging, until I understand more fully what is going on. (As an aside: I also tried writing a regression test in imagej-legacy to replicate the issue, but was unable to do so. The test I tried to write would always successfully discover all the scripts, whether executed from imagej-legacy or imagej.)

Edit: All right, I believe I have a better fix now:

A regression test is still needed before the branch can be merged.

Would interested parties please test the fix-script-discovery branch of scijava-common and let us know if the issue is resolved?


#11

Indeed, this fixes the issue for me on MacOSX. Thanks a lot for that thorough investigation, @ctrueden!

Note that I had to change the order of services in ContextCreationTest to make the test pass (when building on Windows):

From e25dabf15f9ce1c80ce23e394c17a6850015bd7e Mon Sep 17 00:00:00 2001
From: Jan Eglinger <jan.eglinger@fmi.ch>
Date: Wed, 25 Jul 2018 09:32:06 +0200
Subject: [PATCH] Fix service order

---
 src/test/java/org/scijava/ContextCreationTest.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/test/java/org/scijava/ContextCreationTest.java b/src/test/java/org/scijava/ContextCreationTest.java
index 9c6e15c8..0be58b78 100644
--- a/src/test/java/org/scijava/ContextCreationTest.java
+++ b/src/test/java/org/scijava/ContextCreationTest.java
@@ -87,7 +87,6 @@ public class ContextCreationTest {
 	public void testFull() {
 		final Class<?>[] expected =
 			{ org.scijava.event.DefaultEventService.class,
-				org.scijava.script.DefaultScriptService.class,
 				org.scijava.app.DefaultAppService.class,
 				org.scijava.app.DefaultStatusService.class,
 				org.scijava.command.DefaultCommandService.class,
@@ -113,6 +112,7 @@ public class ContextCreationTest {
 				org.scijava.prefs.DefaultPrefService.class,
 				org.scijava.run.DefaultRunService.class,
 				org.scijava.script.DefaultScriptHeaderService.class,
+				org.scijava.script.DefaultScriptService.class,
 				org.scijava.script.process.DefaultScriptProcessorService.class,
 				org.scijava.startup.DefaultStartupService.class,
 				org.scijava.task.DefaultTaskService.class,
-- 
2.16.2.windows.1

Unrelatedly, I had noticed earlier that on Windows (Git Bash), I would have to change assertTrue to assertFalse in FileHandleTest to make all tests pass:

I guess that’s a platform-specific problem, but I never got around to file an issue or PR for that.


#12

Great, I merged it.

Thanks for the heads up; I fixed that oversight before merging.

Thanks for the report. I committed a workaround:

I will cut a new scijava-common and upload to the Java-8 update site before week’s end.


Plugin scripts no longer appear in plugin menu on mac osx
Updator crashes Fiji