Closed NicoKiaru closed 2 years ago
As source names are not final, there's a risk to loose synchronization with the display in the bigdataviewer UI.
Yes, this is an important point.
If possible, it would be best to make source name setting always go through the ViewerState
.
For example, there is already ViewerState.setGroupName(SourceGroup, String)
that will emit a ViewerStateChange
event GROUP_NAME_CHANGED
, is subject to locking/synchronization etc. It would be desirable to have the same for the source names. E.g., if you synchronize on the ViewerState, you can be sure that no-one will change source names under you.
This then leads to the question whether the name should even be a property of the Source
or stored directly in the ViewerState (as for groups). The downside is then that you cannot modify the name of a Source without it being attached to a ViewerState. And the same source shown in different BigDataViewer windows could be given different names (which is good or bad, depending on what you want).
In any case it is important that changing the name must not change the hashcode of the SourceAndConverter
(and therefore Source
). because SourceAndConverter
is the key of the source in the ViewerState.
Ok, that's indeed much more complicated than I thought....
Let's suppose an identical sourceandconverter is present in multiple bdv windows. An orthoviewer could be like that for instance.
If the name of Source
is a property stored in the ViewerState
:
setName
method of Source
(and maybe SourceAndConverter
), but then other bdv windows are not notified, which is not good for synchronization.setName
method of Source
. Then there's no point having a setName method in Source
or SourceAndConverter
. And as you pointed, this means you can have different names for an identical SourceAndConverter
present in different windows. This is not what you want for an orthoviewer...I do not see how a single name can be maintained in sync with multiple bdv windows without replicating a mechanism of listeners like the one present with ConverterSetup
( changing min max / color of ConverterSetup
works well in sync with multiple bdv windows ).
So I see three options:
ConverterSetup
a setName
method, to highjack the already working listeners. One would have to call conversetupt.setName("newSourceName")
to trigger renaming in all linked bdv windows. But :
I'm not sure whether a single ConverterSetup
can be associated with multiple SourceAndConverter
. If that's the case, it's bad because there's no point renaming different SourceAndConverter with the same name.
ConverterSetup
was not meant to do that, so the name can be misleadingConverterSetup
mechanism with a new class which could be called SourceSetup
. While ConverterSetup
deals with the converter change events, the SourceSetup
would deal with the source change events like : renaming, and maybe other things (like changing the converter ?...). But that's quite a big change for something that looks so simple such as a renaming event.I do not see any other solution that would work for multiple bdv windows, and which still allows renaming.
Now if we do not allow renaming and keep the name final. That will be much less work. What could still be super useful is to add a name field in SourceAndConverter
, which would copy the name of the SpimSource by default, and then add SourceAndConverter
constructors with a name parameter which would would allow to override this behaviour. This would allow to have unique names for SourceAndConverter
. But the uniqueness has to be done on the creation of the SourceAndConverter
object. Then the setName
method would throw an unsupported operation exception.
Side notes:
In any case it is important that changing the name must not change the hashcode of the
SourceAndConverter
(and thereforeSource
). becauseSourceAndConverter
is the key of the source in the ViewerState.
Do you override the hashCode
or equals
method of SourceAndConverter
somewhere ? From what I understand in [hashcode javadoc](https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode()), there' s no risk this should happen.
Regarding usage scenario, it's not super straightforward, but here's my use case:
https://youtu.be/tuiaEXmFVyE?t=20
https://user-images.githubusercontent.com/20223054/80470278-11efda80-8942-11ea-86c6-a232eb728e80.png
As soon as I have multiple files, I usually end up with duplicate names in Source or SourceAndConverter. And this prevent me from using macro scripting for instance, because identifying a source is ambiguous. So that's an issue.
Also when using the scijava framework, if an object do not override toString
or is not a Named
object, then it usually have an ugly name in widgets. And because bdv-playground
is internally using SourceAndConverter
objects, it currently have ugly name.
Ok, maybe not everything is useful here, but the issues we are facing with @tischi in the bdv-playground repo are :
This means the names are not final anymore. Is this acceptable ?
By default
SourceAndConverter
objects take the name of the associatedSpimSource
given in the constructor, or duplicate the name if the constructor called is the one which needs aSourceAndConverter
as an input. This initialSourceAndConverter
name can be changed by using the methodSourceAndConverter::setName
.There is a default
setName
method which throws an exception in theSource
interface. This avoids creating asetName
method for all the other projects which depend on bigdataviewer-core. But is this a good idea ? Removing the default setName would force to have a correct implementation forSource
subclasses, instead of throwing an exception.As source names are not final, there's a risk to loose synchronization with the display in the bigdataviewer UI.