MVS: IHM support

[dsehnal]

Description

Adds better support for I/HM structure in MolViewSpec

• Support coarse components
• Support spacefill representation
• Support element_granularity in component expressions
• If no color theme is specified explicitly, use Mol*'s defaults instead
• Add atom.ihm.has-seq-id symbol to the query language

https://pdb-ihm.org/cif/8zz1.cif with crosslink restraints:

Actions

• Added description of changes to the [Unreleased] section of CHANGELOG.md
• Updated headers of modified files

[midlik]

Looks fine but some things are not clear to me - see comments.
Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

[midlik]

Here we are making sure MVS is pretty much Molstar-specific and no one will ever implement it for any other viewer.

[dsehnal]

I disagree. You can still implement explicit colors. And this could be defined as expected behavior (= colors determined by viewer if not specified explicitly).

And we focus on iterating on color in "MVS 2.0".

[dsehnal]

I have an alternate solution to support "vendor extension" to do that. Thanks for the feedback.

[midlik]

I thought the original idea was that a MVS view should look roughly the same in all viewers.
With this, a representation node without specified color can look very different in different viewers.
So as a user, I might think I have created a beautiful view where each chain has a different color, but then I load it in PyMOL it will be all magenta because default per-chain coloring was just Molstar's implementation detail.

[dsehnal]

You are right, I will implement the auto mol* coloring as a custom extension on the color node.

[midlik]

Does this mean that if label_seq_id is not present, it will select from both atomic and coarse parts of the structure?

[dsehnal]

Actually, we can completely remove element_granularity in this case and just use the ihm.hasSeqId.

[midlik]

Hmmm, if we can remove element_granularity, let's do it. One thing less for the user to worry about.

[dsehnal]

Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

My goal was to make this work with the primitives here. @midlik you wrote this code, so do I need to change anything else for things you mention to work or is this fine? Can also do this in a separate PR.

[midlik]

Also, have you tested if the new selections work in all possible contexts (I mean, as inline component, as *_from_uri, as target for primitive...)?

My goal was to make this work with the primitives here. @midlik you wrote this code, so do I need to change anything else for things you mention to work or is this fine? Can also do this in a separate PR.

If we remove element_granularity, it should work in all context, i think.
If you want i can test it (just ping me once you remove element_granularity)

[dsehnal]

If we remove element_granularity, it should work in all context, i think.
If you want i can test it (just ping me once you remove element_granularity)

@midlik
Ready for re-review/testing. Thanks