TMI ? - having now looked at CollectionColourScheme I realised you've pushed ColourSchemeI to a lower level - implementers are used by the CollectionColourScheme to compute colours based on the info it provides. The findColour method signature still feels too specific tho'.
Superclass method shows or hides viewerActionMenu, not viewSelectionMenu. ChimeraViewFrame overrules that to show viewerActionMenu. Logic to hide viewSelectionMenu could be moved to superclass method instead. It might be puzzling (why hide an item in a hidden menu?).
Is there a use case for having a SequenceGroup without a context ? If so, the group could use SequenceI.isNucleotide() to give an accurate response rather than simply returning 'false' regardless. You need to make a note in javadoc if nothing else to warn the casual coder!
I still feel like TMI is needed by the implementor for a 'simple' colourscheme. If instead of returning asColourSchemeI, one could return as ComplexColourSchemeI or as SimpleColourSchemeI , and have a handler implement isSimple, that would make this cleaner.
Merging these does make sense (though we should bear in mind that Jalview features could be used to distinguish disulphide bonded from reduced cysteines), but now the 'Threshold' doesn't - don't you mean <100% here ?
this javadoc doesn't really reflect what actually happens - which is that the name should resolve to one of the currently registered colourschemes, or parseable as a single colour or set of user defined symbol colours. Suggest you remove any explicit list of colours at least
CollectionColourScheme(I) is more than a data bean - it also holds the logic for deciding what colour the renderer will use given a particular row, column, sequence, group and viewport settings. Suggest it be renamed and moved from schemes to renderer (perhaps renderer.residueshader ???)
I think this is very nearly ready to merge to develop. A couple of ambiguities regarding the class/interface architecture that might be worth revising before the merge, but otherwise the patch looks to maintain functionality (and, of course, fix several bugs).
This should be refactored from Phyre2Client - allowing the jalview.io.AnnotationFile's STRUCTMODEL statement handler to call it.
Once you've refactored, please provide a code sample that allows a single structure model provided as a PDB file to be associated with its target (where sequence matches), and template (where match is given by the loaded alignment)