examples

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'master' into releases/Release_2_11_2_Branch

  1. … 6 more files in changeset.
patch needed for 2.11.2 - JAL-3518 - catch case when no replies are available

patch needed for 2.11.2 - JAL-3518 - catch case when no replies are available

semantics for determining if a PDB file has a SIFTs mapping - could be absorbed into the PDB metadata object

semantics for determining if a PDB file has a SIFTs mapping - could be absorbed into the PDB metadata object

magic logic to recognise which structure database provider client to use - PDB or AlphaFold - ensures metadata and annotation rows are propagates

magic logic to recognise which structure database provider client to use - PDB or AlphaFold - ensures metadata and annotation rows are propagates

Reviewing the alphafold + contact matrix patch for 2.11.2
Reviewing the alphafold + contact matrix patch for 2.11.2
WIP
WIP
update test for JAL-3763 redact shared DS sequences for contiguous CDS

JAL-3748 test data for SplitFrameTest

    • binary
    ./testdata/MN908947.jvp
JAL-3407 add and document ComputePeptideVariants.groovy

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

    • -0
    • +32
    ./groovy/exportconsensus.groovy
JAL-3536 failing test and test data

    • binary
    ./testdata/CantShowEnsemblCrossrefsTwice.jvp
  1. … 1 more file in changeset.
Test file relocated to test/jalview/io.

Test file relocated to test/jalview/io.

JAL-3141 test file in test folder not examples

  1. … 2 more files in changeset.
JAL-3150 examples/exampleFile.jvp for updated manual/tutorial exercises

JAL-3127 scripts updated for method signature change

May be worth adding temp.deleteOnExit() in case anything goes wrong with renaming later

May be worth adding temp.deleteOnExit() in case anything goes wrong with renaming later

Needs Javadoc; in particular to highlight the side-effect (that a file is written)

Needs Javadoc; in particular to highlight the side-effect (that a file is written)

Use '.' (test/jalview/io) rather than examples (which should be kept for real user data files). Or better if possible, use File.createTempFile to save files to a system-managed temporary folder.

Use '.' (test/jalview/io) rather than examples (which should be kept for real user data files).
Or better if possible, use File.createTempFile to save files to a system-managed temporary folder.

JAL-2250 now done.

JAL-2250 now done.

exampleLabel (and label.suffix_example_filenames) removed (had been taken out to save vertical space in the Preferences pane).

exampleLabel (and label.suffix_example_filenames) removed (had been taken out to save vertical space in the Preferences pane).

Is exampleLabel needed? Doesn't seem to do anything.

Is exampleLabel needed? Doesn't seem to do anything.

In BackupFiles it started off as (and remains) simply a boolean flag. Being able to convey that in the user preferences would be too terse so I agree that I wanted to expand that to look like a bin...

In BackupFiles it started off as (and remains) simply a boolean flag. Being able to convey that in the user preferences would be too terse so I agree that I wanted to expand that to look like a binary choice. I still wanted it to behave like a boolean flag though to keep the code readable in GPrefences. Also I knew I wanted to do this more than once, and I suspect that if I'm adding anything similar to Preferences in the future I'll want to use it again, it just seemed tidier to bundle it off, with checks and balances, into another class. If I ever have to change those checks and balances I'll be glad it's in a separate class and not spread around GPreferences in multiple places!

Ah I see, yes that is different behaviour. Though your class is still just wrapping a simple test like if (trueButton.isSelected()) I still think this is not so much a boolean as a binary choice ...

Ah I see, yes that is different behaviour.
Though your class is still just wrapping a simple test like

if (trueButton.isSelected()) 

I still think this is not so much a boolean as a binary choice (both options 'mean' something).
And that doing the exact same thing with two radio buttons directly would be simpler.

I'm not sure this is the same. jalviewBooleanRadioButtons.isSelected() should return true only if buttonTrue is selected and buttonFalse isn't selected. It will return false if both are selected (w...

I'm not sure this is the same. jalviewBooleanRadioButtons.isSelected() should return true only if buttonTrue is selected and buttonFalse isn't selected. It will return false if both are selected (which is not possible[!] but would be ambiguous), or neither are selected (possible but also ambiguous), or crucially if buttonFalse is selected (unambiguously return false). The two expected scenarios are one xor other are selected, with isSelected() returning either true or false. I assume buttonGroup.getSelection() != null will return true if buttonFalse is selected (sorry not had time to check this in reality)? This is how I was wanting the two button radio group to behave like a checkbox but be more visually explicit in the user preferences.

I don't really like creating work for myself, but my experience (in a different arena, so might not apply here) is that scope-creep is common and future features get asked for a couple of years dow...

I don't really like creating work for myself, but my experience (in a different arena, so might not apply here) is that scope-creep is common and future features get asked for a couple of years down the line, even when they've been specifically ruled out at the design stage! My over-spec compensatory coding stems from that experience, but I'm happy to believe that occurs less here. I guess I also think a method named "lsBackupFiles" should definitely have the ability to return a list! Now that's changed I guess I don't have to!

Golden rule (for me, but not just for me) is not to write code you don't need (and refactor if needed in the future). Why not just have a getBackupFiles that returns TreeMap, then Groovy is free to...

Golden rule (for me, but not just for me) is not to write code you don't need (and refactor if needed in the future).
Why not just have a getBackupFiles that returns TreeMap, then Groovy is free to use as it wishes e.g. files.values().iterator().
More flexible than guessing what view of the files might be wanted in future.

addTrueActionListener can be removed without changing behaviour. addFalseActionListener isn't used. Don't need either.

addTrueActionListener can be removed without changing behaviour.
addFalseActionListener isn't used.
Don't need either.

Or buttonGroup.getSelection() != null (the ButtonGroup is what 'knows' whether anything is selected)

Or buttonGroup.getSelection() != null (the ButtonGroup is what 'knows' whether anything is selected)

I still need convincing. Nothing to stop you adding the six radio buttons directly (in three ButtonGroups) to achieve the same result. Avoids the need for getTrueButton, getFalseButton.

I still need convincing. Nothing to stop you adding the six radio buttons directly (in three ButtonGroups) to achieve the same result. Avoids the need for getTrueButton, getFalseButton.