bigdataviewer/bigdataviewer-playground

DisplayService Bug?

Closed this issue · 10 comments

			displayService = SourceAndConverterServices.getSourceAndConverterDisplayService();
			displayService.show( bdvHandle, sourceAndConverter );
			final Set< BdvHandle > bdvHandles = displayService.getDisplaysOf( sourceAndConverter );

Running above code results in an empty Set< BdvHandle >.
Am I doing something wrong?

Hum, how did you created the BdvHandle ?

For the BdvHandle to be recognized by bdv playground, it needs to be registerd in scijava.

The most simple way is to declare bdvhandle as an output parameter in a command:

    /**
     * This triggers: {@link sc.fiji.bdvpg.scijava.processors.BdvHandlePostprocessor}
     */
    @Parameter(type = ItemIO.OUTPUT)
    public BdvHandle bdvh;

The post processor (check BdvHandlePostprocessor) is doing a few things:

  • registered the bdvhandle in scijava objectservice - make sure its name is unique - which is useful for macro scripting
  • creating a tree node containing all sources present inside the bdvhandle (and listening to their changes)
  • taking care of removing the bdvhandle from the objectservice if the user closes the window

In BDV Playground like this:

	private BdvHandle createBdv()
	{
		BdvCreator creator = new BdvCreator( BdvOptions.options(), true, 1 );
		creator.run();
		return creator.get();
	}

Probably I should use: BdvWindowCreatorCommand?

Maybe we should add a warning to the documentation of BdvCreator that one also needs to register it. Could one also register it oneself?

Hum, now I did it like below and it still returns an empty list...

	private BdvHandle createBdv()
	{
		final BdvWindowCreatorCommand command = new BdvWindowCreatorCommand();
		command.is2D = is2D;
		command.interpolate = true;
		command.nTimepoints = 1; // TODO
		command.windowTitle = "MoBIE"; // TODO
		command.projector = Projection.MIXED_PROJECTOR;
		command.run();

		return command.bdvh;
	}

Indeed, calling the command this way does not trigger the pre and postprocessors. This part is one of the few which relies on scijava. You need a CommandService or duplicate what happens in the post processor. We can also remove what s in the post processor to make it more accessible. It s probably a good idea

We can also remove what's in the post processor to make it more accessible. It s probably a good idea

Yes, factoring out what happens in the post-processor as a standalone BdvHandleRegisterer class sounds like a good plan!

Should we then maybe also call the BdvHandleRegisterer within BdvCreator? Then users of the library, like myself, would not need to worry about it ;-)

I can make a PR tomorrow, if you wish.

Maybe we don't need an extra class; should we add it like this? Would maybe be a natural place to look for it and also within the SourceAndConverterBdvDisplayService we have access to all the SciJava services that we need for the job.

SourceAndConverterBdvDisplayService.registerBdvHandle( BdvHandle bdvh )

I am trying to implement, but I need to access this method

   public SourceAndConverterServiceUI getUI() {
        return ui;
    }

which is currently not within ISourceAndConverterService.

Should I add it to the interface?

You can cast to SourceAndConverterService to access it. There's only one implementation of the service.

I'm not sure if it is a good idea to change the interface. I honestly don't know.

You can cast to SourceAndConverterService to access it. There's only one implementation of the service.

That's what I did ;-)

You could look at the PR

the PR was merged, I guess this means we can close this issue