Jalview Code Reviews

Merge branch 'develop' into improvement/JAL-3420_match_jvl_icon_with_new_website_jvl_icon

new jvl_file svg, png, ico and icns files, and changed references to Jalview-Launch to jvl_file

    • binary
    /utils/install4j/jvl_file.icns
    • binary
    /utils/install4j/jvl_file.ico
    • binary
    /utils/install4j/jvl_file.png
    • -0
    • +94
    /utils/install4j/jvl_file.svg
JAL-3137 tests are for linux only

    • -1
    • +1
    /test/jalview/bin/HiDPISettingTest2.java
Merge branch 'merge/develop_JAL-3725' into develop

Conflicts:

src/jalview/gui/PopupMenu.java

    • -3
    • +65
    /src/jalview/util/MappingUtils.java
    • -52
    • +138
    /test/jalview/util/MapListTest.java
    • -25
    • +15
    /test/jalview/util/MappingUtilsTest.java
Merge branch 'develop' into JAL-3416_different_look_and_feel_on_linux

update to flatlaf 2.0.1

    • binary
    /j11lib/flatlaf-2.0.1.jar
    • binary
    /j8lib/flatlaf-2.0.1.jar
Merge branch 'bug/JAL-3633_read_proxy_settings_from_jalview_properties_in_getdown' into develop

Conflicts:

src/jalview/bin/MemorySetting.java

    • -0
    • +11
    /resources/lang/Messages.properties
    • -0
    • +11
    /resources/lang/Messages_es.properties
    • -73
    • +179
    /src/jalview/bin/MemorySetting.java
    • -0
    • +323
    /src/jalview/jbgui/GPreferences.java
Merge branch 'develop' into releases/Release_2_11_2_Branch

JAL-3763 (for whatever reason) need to increase timeout for command line ops to 10.5s (OSX Monterey, MBP late 2018)

    • -1
    • +1
    /test/jalview/bin/CommandLineOperations.java
Merge branch 'develop' into releases/Release_2_11_2_Branch

JAL-3746 note about adding JAL-3700,JAL-3751,JAL-3763 release notes

Merge branch 'merge/develop_task/JAL-3763_newDatasetForCds' into develop

JAL-3763 (for whatever reason) need to increase timeout for command line ops to 10.5s (OSX Monterey, MBP late 2018)

    • -1
    • +1
    /test/jalview/bin/CommandLineOperations.java
Merge branch 'task/JAL-3763_newDatasetForCds' into merge/develop_task/JAL-3763_newDatasetForCds

Conflicts:

src/jalview/analysis/AlignmentUtils.java

src/jalview/util/MapList.java

test/jalview/util/MapListTest.java

test/jalview/util/MappingUtilsTest.java

    • -55
    • +41
    /src/jalview/analysis/AlignmentUtils.java
    • -2
    • +4
    /src/jalview/datamodel/SearchResults.java
    • -53
    • +53
    /src/jalview/util/MappingUtils.java
    • -2
    • +114
    /test/jalview/util/MappingUtilsTest.java
Merge branch 'develop' into releases/Release_2_11_2_Branch

Merge branch 'releases/Release_2_11_1_Branch'

JAL-3940 update 2.11.2 release notes for 2.11.1.7 patch release (again)

JAL-3940 errant heading in release notes..

Merge branch 'patch/r2_11_1_branch_JAL-3703_closing_files' into releases/Release_2_11_1_Branch

I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behavio...

I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behaviour wouldn't have too many side effects.

The intended pattern for FileParse.close() was:

ParserThing pt;
try {
pt = new <? assignable to FileParse>(data spec..)
.. do whatever needed to trigger parsing
.. then check pt's error/warning status and report any problems.
} catch (IOException ..) {
.. handle read or parse errors 
}
finally {
if (pt!=null) {
pt.close();
} // catch and report any IOErrors if desired
}
I tried this first, but FileParse.close() deliberately leaves the FileParse in an error state, which caused problems later (I don't remember the specifics). I could not work out why the FileParse.c...

I tried this first, but FileParse.close() deliberately leaves the FileParse in an error state, which caused problems later (I don't remember the specifics). I could not work out why the FileParse.close() was designed to do this but suspect changing this methos so it's (in general) not left in an error state will cause bigger problems. Also, since Jalview is used to having dataIn for the lifetime of the alignment, I wasn't sure if nulling the object would cause unforeseen errors (in e.g. filename etc).

Maybe it would be best to overload FileParse.close() to pass in an error value/message, then it would essentially be calling FileParse.closeDataIn() instead of FileParse.dataIn.close()

Agree with the finally {} – forgot that (not been a java programmer for quite long enough!). Presumably that should go in FileParse and not AlignFile too.

JAL-3703 patch Windows save file test for 2.11.1 codebase

Merge branch 'patch/r2_11_1_branch_JAL-3703_closing_files' into releases/Release_2_11_1_Branch

JAL-3940 fix issues in release notes

JAL-3940 update 2.11.2 release notes for 2.11.1.7 patch release

JAL-3940 bump version and update release notes - release set for Tuesday 18th January 2022

JAL-3940 update release notes for JAL-3702,JAL-3935 in 2.11.1.7 release

Merge branch 'develop' into releases/Release_2_11_2_Branch

JAL-3746 possible release date 1st Feb 2022

JAL-3746 Release notes for patch JAL-3702 JAL-3915