groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
JAL-1950 patch groovy bootstrap for importing hmmer3 json

WIP
WIP
JAL-3641 allow protocol to be configured at top of script

JAL-3641 prototype FASTQ import via groovy script for 2.11.1

    • -0
    • +155
    ./FastQParser.groovy
JAL-518 quick and dirty groovy script implementing undo/redo left justify (or right if the flag is disabled)

    • -0
    • +84
    ./justifyRegionQuick.groovy
JAL-3407 add and document ComputePeptideVariants.groovy

    • -0
    • +32
    ./ComputePeptideVariants.groovy
  1. … 3 more files in changeset.
JAL-3548 start an http server for posting gene ids to retrieve from ensembl and display in Jalview

    • -0
    • +45
    ./simpleHttpServlet.groovy
  1. … 4 more files in changeset.
JAL-3547 groovy script to get the conservation sequence and output it as fasta

    • -0
    • +32
    ./exportconsensus.groovy
JAL-3210 Barebones gradle/buildship/eclipse. See README

    • -75
    • +0
    ./annotationForSelectedSequence.groovy
  1. … 1976 more files in changeset.
JAL-3417 prototype sdppred calculation as groovy script

    • -0
    • +70
    ./sdppred_testing.groovy
JAL-3127 scripts updated for method signature change

JAL-2250 now done.

JAL-2250 now done.

we don't have consistent colourscheme class docs. will add minimal.

we don't have consistent colourscheme class docs. will add minimal.

Took a closer look and the hiddenRepSequences is indeed redundant (assuming we only care about represented sequences held by the view, not some other aggregation). Have also raised JAL-3156 - since...

Took a closer look and the hiddenRepSequences is indeed redundant (assuming we only care about represented sequences held by the view, not some other aggregation). Have also raised JAL-3156 - since there's an inconsistency in how SequenceCollectionI.getSequences(..) is implemented - for groups, all the hidden represented sequences are returned, but for an alignment, none of them are. This is quite subtle, but will be more important when we implement automated selection of representative sequences.

yeah. tidied that whole block up but included the containing conditional.

yeah. tidied that whole block up but included the containing conditional.

...but (afterthought!) include a check for av.getGlobalColourScheme() == null (No Colour case).

...but (afterthought!) include a check for av.getGlobalColourScheme() == null (No Colour case).

I'll look at this again, anyway. At the time I thought a 'structure view may be dirty' flag was easier to implement than track down every case where AlignPanel.updateAnnotation() is called (this is...

I'll look at this again, anyway. At the time I thought a 'structure view may be dirty' flag was easier to implement than track down every case where AlignPanel.updateAnnotation() is called (this is currently what TreePanel calls to update each associated view), in the spirit of JAL-2773.

Could be pushed into AlignPanel

Could be pushed into AlignPanel

JAL-2250 is still not resolved. I've marked it as a blocker for Jalview 2.11

JAL-2250 is still not resolved. I've marked it as a blocker for Jalview 2.11

If you call ssm.sequenceColoursChanged(this) when a tree cut occurs, a second call will still be need to adjustAnnotationHeight() anyway. Other ways of modifying the alignment view also call adjust...

If you call ssm.sequenceColoursChanged(this) when a tree cut occurs, a second call will still be need to adjustAnnotationHeight() anyway. Other ways of modifying the alignment view also call adjustAnnotationHeight, with the expectation that updates will be propagated to associated structure and overviews. Either we recode every other caller to also explicitly update structure views (regardless of if there is one or not) before triggering an overview repaint, or we push all the conditional event handling to the end.

Which way do you vote ?

The mechanism to update structure colours on change of group colours seems over-complicated. It sets a flag on the viewport which is checked at some future point (chosen to be in AlignmentPanel.adj...

The mechanism to update structure colours on change of group colours seems over-complicated.
It sets a flag on the viewport which is checked at some future point (chosen to be in AlignmentPanel.adjustAnnotationHeight()) and if set
ap.paintAlignment(true, true);
which in turn triggers a call to
av.getStructureSelectionManager().sequenceColoursChanged(this);

Why not just make this call at the time of setting the group colours (it works!)?
Then the new flag wouldn't be needed.

Can be simplified to av.getGlobalColourScheme().getInstance(av, sg, null);

Can be simplified to
av.getGlobalColourScheme().getInstance(av, sg, null);

Actually, 'Apply Colour to all Groups' is unchecked by default - except after loading from project, when it is checked, even if unchecked when saved :-O.

Actually, 'Apply Colour to all Groups' is unchecked by default - except after loading from project, when it is checked, even if unchecked when saved :-O.

add IDColourScheme to JalviewColourSchemeTests

add IDColourScheme to JalviewColourSchemeTests

Maybe "By Sequence ID". NB: for i18n, have to add to message bundles, compare label.colourScheme_t-coffee_scores = T-Coffee Scores label.colourScheme_t-coffee_scores = Puntuación del T-Coffee

Maybe "By Sequence ID".
NB: for i18n, have to add to message bundles, compare
label.colourScheme_t-coffee_scores = T-Coffee Scores
label.colourScheme_t-coffee_scores = PuntuaciĆ³n del T-Coffee

Is it possible to drop the hiddenRepSequences argument now (read it from viewport.getHiddenRepSequences()?). It seems to only be used by ClustalxColourScheme. Not sure if it needs to be null in the...

Is it possible to drop the hiddenRepSequences argument now (read it from viewport.getHiddenRepSequences()?).
It seems to only be used by ClustalxColourScheme.
Not sure if it needs to be null in the group colour case though...

could move this outside the loop

could move this outside the loop

in fact this test is not needed (is applied at the top of this method). Could simply call setColor((SequenceNode) node.left(), c); setColor((SequenceNode) node.right(), c); here

in fact this test is not needed (is applied at the top of this method).
Could simply call
setColor((SequenceNode) node.left(), c);
setColor((SequenceNode) node.right(), c);
here