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