More flexible way to create annotation legend
EliotRagueneau opened this issue · 17 comments
In earlier versions, you provided a way for us (IntAct at least) to create our own legend based on the annotation legend.
Now you do all of that by yourself and it is really nice, but it doesn't really match the specific needs for IntAct for instance, as the complex is really an interaction, and we don't need the intact_ before the ac.
I think you suited the annotations for the complex portal needs (which is really appreciated), but then for IntAct, or I guess any other users, it would be great if we could customise or create our own legends.
Right now, I fixed it on my side by replacing the terms I didn't want with jquery whenever the legend is updated, but it's not really a proper way to do it. (e.g. in interaction details).
I see several options for these problems:
- Fire events when the annotation is changed with the different annotations colours with their data (Solution used before I think)
- Create an "AnnotationLegendRenderer" interface that takes the data as input and produce the legend, take the current version as the default implementation, and give the possibility to set the renderer and maybe to inherit the default one make our own
- Give the ability to provide functions for the annotation groups and titles, and apply them in your current "renderer". It would make a signature like this I think:
viewer.addColorSchemeKey(location: DOMElement,
groupTitleModifier: (groupTitle: string) => string = groupTitle => groupTitle,
annotNameModifier: (annotName: string) => string = annotName => annotName
)(The default unity function being there to allow not to provide those functions by default, and yet apply them in your renderer without any impact)
What do you think of all that?
By the way sorry, I am working with typescript on Angular, and I don't think that there is really notions of interface or such kind of things with proper js, but I think we could still find a way to make one of these solution work in plain old js
you can get the current feature colour scheme with
viewer.getFeatureColors();
its a d3 color scale
the colour scheme can only change by the choice of annotations being changed, so you already know about this on your side?
If I observed well, the index begins at 5 for the colour range. That's fine.
However, how can I get the colour scheme used for the complexes? Because I've been looping over the whole feature range and I couldn't find the complex colour (I could use a static one for now since we only show one complex at a time, but when we will expand interaction's complexes, the problem will be there ...)
Nevermind, it's getComplexColors(), thank you very much
It should be more than enough for our needs 😄
Actually, there is one problem with this: knowing the corresponding annotation. I can browse the MIJson as you do for collecting interaction names and MI Features, but for the one that you query on your side (UniProt and SuperFamily), I would need to query them as well on my side, and it's not the best in terms of optimisation ...
We could disable the other annotations type, but they are really nice features I think, so I would prefer to keep them ...
A solution could be to return an object like this when we set/show an annotation type, depending on what is actually shown
{
"Complex": [
{"name": "intact_EBI-1004454", "color":"#aec4f"}
],
"MI Features": [
{"name": "bla", "color":"#xxxxxx"},
{"name": "blabla", "color":"#yyyyyy"},
]
}yep, you're right.
the information is stored in the proteins, the confusing code where I get it back out to make the legend is here: https://github.com/MICommunity/ComplexViewer/blob/bc89b81a55774311e2c742068b802d62f51cee03/src/js/color-scheme-key.js#L32-#L49
I think returning an object from the set/show annotation function just like you say is best solution, it sorts out something that's kind of a mess.
(should probably also have a getter function that returns same thing, also removes the need for this getComplexColours function so I'll take that out)
Hi @EliotRagueneau - happy new year.
I made some changes along the lines of what we discussed - not super thoroughly tested but let me know how you get on, and any other suggested changes you have.
A solution could be to return an object like this when we set/show an annotation type
Ok, it does this now. There's no way to register a listener for colour scheme changes, might be nice to have but think we maybe don't actually need it? (The old stuff to do with ComplexViewer generating legends in div's is still there but should maybe be removed.)
Hi @colin-combe, happy new year to you too!
I'll test that and give you feedback, but that looks awesome 😄 .
OK so as I said in the other issue, we tested the new functionalities and its awesome. One thing we could maybe improve for this legend is to tell whether the colour should be hatched or not in the legend, so that it really reflects what's on the viewer.
Otherwise, it's already much better to customise the legend this way, thank you very much!
One thing we could maybe improve for this legend is to tell whether the colour should be hatched or not in the legend, so that it really reflects what's on the viewer.
Yep, you're sort of right about that. But also the colour for a certain feature could be both hatched and unhatched - the certain regions are unhatched and the uncertain are hatched, some have both:-
Also, it looks like I made the colour for the hatched areas slightly lighter.
I think you're right that this could be better. Maybe show both hatched and unhatched in legend? I guess what you would ideally want in that json is info on whether the colour appears hatched, unhatched, or both.
I guess what you would ideally want in that json is info on whether the colour appears hatched, unhatched, or both.
Yes, that would be perfect to have this information in the JSON.
I thought that the lighter tone was just an optical illusion but apparently it's not, do you want to keep it this way (which looks nice)? If so, I guess we'll need the colour used for the hatching in the JSON too.
If so, I guess we'll need the colour used for the hatching in the JSON too.
lets keep it and lighten the hatches in the legend, as you say
(i made the hatched areas lighter so they were less jarring to look at, a more consistent thing might have been to lighten both hatched and unhatched areas, but I think i tried that and decided the darker colours were better for unhatched areas...)
so, I'll add that info to the json
That's awesome thanks!
bear with me Eliot... next week for this
Thank you, Colin!
Unfortunately, I'm no longer working for IntAct but for Reactome now, but I'm sure Noe will take good care of all this.
it's now done as @EliotRagueneau suggested, you can see it as complexviewer.org
I think its better, so thanks
It's really a good result, thank you very much!