Headless mode

[hadim]

We should add an option when starting the kernel to run it in headless mode or not.

Or we could install two kernel specification (two kernel.json files):

• SciJava Headless
• SciJava

[ctrueden]

It is possible to kick the kernel into headless mode by doing:

// @UIService ui
ui.setHeadless(true)

Or perhaps even:

System.setProperty("java.awt.headless", "true")

At the top of your notebook.

I also have a pretty clear vision for how to mitigate the problems non-headless causes—in particular, we can handle cell outputs ourselves such that the DisplayPostprocessor does not start snarfing them up and popping windows.

Working on it now.

[hadim]

If we can avoid having a kernel option, I am in favor of that.

[hadim]

The ui.setHeadless(true) trick allows notebooks to be executed on Travis (for testing purpose).

I propose that by default we enable the headless mode (by modifying the Java command that launches the kernel). Then if people want to have access to the IJ1 UI (for RoiManager or something else), they would still be able to use ui.setHeadless(false) right ?

[ctrueden]

@awalter17 and I had the same idea and tested it, but unfortunately it does not work. If you pass java.awt.headless=true to the JVM at startup, then some internal machinery is triggered which results in the JVM immutably being in headless mode. We even tried a couple of hacks to kick it out of headless mode, but no dice.

The other way, on the other hand, seems to work OK: start the JVM normally, and if a display is available, it can be used including GUI stuff—and then call ui.setHeadless(true) in an early cell to disable the GUI subsequently. I believe this approach triggers less thorough machinery; in a nutshell, there is a difference here between hard headless mode ("I must run headless") vs. soft headless mode ("I choose to run headless" at the moment).

I am a little surprised that you needed an explicit ui.setHeadless(true) to make things work on Travis. The JVM should already launch in hard headless mode by default when no UI subsystem is available.

Perhaps some judicious web searching can shed more light on this issue.

[hadim]

Ok then using ui.setHeadless(true) is good enough for me.

About Travis to be honest I don't really understand what is going on. Notebooks randomly fail to execute when I execute them all. That is why I now only execute the Test.ipynb notebook. It used to fail too but with ui.setHeadless(true), it seems to work (3 builds successful so far). So as long as it works I don't really care (I spent hours trying to debug Travis a few weeks ago to finally give up).

[hadim]

Feel free to close here.

[ctrueden]

If the Travis issue continues, I can try to find time to debug it later this summer. Another option is that if the tests work properly most of the time, we can add logic to execute each test multiple times per build, and then fail the build only if the test fails every time.

As for headless in general, we can stick with the current approach for now, and look into improvements later. Headless should in general be working. And @awalter17 and I already added logic to prevent the outputs from popping up UI when running with a display. We do still need to manage inputs better—i.e., not pop up the input harvester—but I consider that a separate issue than this one.

[hadim]

Perfect.

(about the input, it will probably require the development of a JS extension/plugin on the client side, but as you said it's a separate issue)