jalview

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
This is likely an improvement on the "roll your own" pattern of setting Runnable handlers for dialog responses as hacked together for JalviewJS (JAL-3048). If so, it would be preferable (but no sma...

This is likely an improvement on the "roll your own" pattern of setting Runnable handlers for dialog responses as hacked together for JalviewJS (JAL-3048). If so, it would be preferable (but no small job) to change all dialogs to this pattern.

There are still numerous dialogs that have not been changed to either pattern (so won't work in SwingJS): see comment at https://issues.jalview.org/browse/?focusedCommentId=20525&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#JAL-3048comment-20525.

Class has some compiler warnings which could easily be resolved (typed Hashtable, unused import).

Class has some compiler warnings which could easily be resolved (typed Hashtable, unused import).

It would be good to add Javadoc to this method

It would be good to add Javadoc to this method

As an aside, I would suggest inlining (removing) the two overloaded constructors that call this one (to reduce code bloat).

As an aside, I would suggest inlining (removing) the two overloaded constructors that call this one (to reduce code bloat).

JAL-3818 process Jmol callbacks in AWT thread
JAL-3818 process Jmol callbacks in AWT thread
Or can it be compiled to Java 8 bytecode?

Or can it be compiled to Java 8 bytecode?

'var' is since Java 10. We are still supporting Java 8 runtime which will not run this code (sadly). Compile with JDK 8 to find other occurrences (also Preferences, line 596 is not Java 8 compatibl...

'var' is since Java 10. We are still supporting Java 8 runtime which will not run this code (sadly).
Compile with JDK 8 to find other occurrences (also Preferences, line 596 is not Java 8 compatible syntax).

Above statement is a duplicate - should only be inside the check for service != null. It fails with NPE if service is null.

Above statement is a duplicate - should only be inside the check for service != null. It fails with NPE if service is null.

startjob and canceljob are only referenced in jbinit() so should be local variables in that method.

startjob and canceljob are only referenced in jbinit() so should be local variables in that method.

Field startJob used to be the return value of showRunDialog(). As it no longer is, it can be removed.

Field startJob used to be the return value of showRunDialog(). As it no longer is, it can be removed.

JAL-3809: Edit web service parameters dialog does not work in jalviewjs
JAL-3809: Edit web service parameters dialog does not work in jalviewjs
Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

Agreed. I seem to remember (this was a while ago now) that I found isAMacAndNotJS() and thought it might be an important distinction. Sounds like it's just redundant? Can tidy this another time then.

Agree this is just touching on a much bigger task. However... The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview...

Agree this is just touching on a much bigger task.
However...
The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview.bin.Launcher, jalview.bin.HiDPISetting, jalview.bin.MemorySetting) run very early on (especially jalview.bin.Launcher!). This means Cache.log has perhaps not yet been initialised, so a Cache.log.debug doesn't log (unless you count reams of NullPointerExceptions as logging!).

In the case of HiDPISetting and MemorySetting that also get used in Getdown, where there is no jalview.bin.Cache, they currently have to use System.out and System.err [or maybe I could stub jalview.bin.Cache too]. I'd prefer them to use Cache.log when they can so this is an attempt at starting to decouple jalview.bin.Cache from other jalview things so it can be used standalone within Getdown. The main reason for wanting to do that is to have shared code to read the preferences between Jalview and Getdown.

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly u...

I think there are lots of things that could be tidied up (particularly the overloading and additional logging functions via Cache which don't really reduce code at point of use, but are certainly useful in spirit), but now is most definitely not the time to optimise and beautify code.

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS,...

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS, so probably not a dealbreaker. Do you agree ?

JAL-3608 cherry pick of 92cb745e7
JAL-3608 cherry pick of 92cb745e7
JAL-3762 check for !args || args=="" before overwriting

JAL-3762 more typo fixing :q

JAL-3762 syntax error typo

JAL-3762 check if Info.args already defined before overwriting it with URL args. Also stashes URL args at Info.urlargs

JAL-3751 only merge strictly contiguous ranges of mappings
JAL-3751 only merge strictly contiguous ranges of mappings
JAL-3700: Complement sequence correspondence is broken for CDS with shared dataset sequence
JAL-3700: Complement sequence correspondence is broken for CDS with shared dataset sequence
Decision made in the issue to just check release build_properties.

Decision made in the issue to just check release build_properties.

I'll add a Test. Perhaps this stems from me misunderstanding a comment in the issue: "We should provide a way to find out what the latest version available from a channel is. I suggest we have a b...

I'll add a Test.

Perhaps this stems from me misunderstanding a comment in the issue: "We should provide a way to find out what the latest version available from a channel is. I suggest we have a build details URL for each channel".
For non-Release/Test channel versions the "remote" build_properties will be a local file://.../getdown/website/11/alt/build_properties (which works if you're on the machine you built it on).
For Release/Test channel versions, the remote build_properties will be the most recent one available in https://www.jalview.org/getdown/release/11/release/build_properties (or test/1.8/alt etc). It is true that if this is the case then getdown SHOULD have already updated the jalview.jar. This is fine, and you would expect nothing to be reported anyway.
If you're using the shadowJar or an otherwise non-updatable version of Jalview or for whatever reason getdown has not auto-updated then you will get the message saying what the most recent version (in your channel) is. [This is perhaps the main part of the target audience for this message now???]
If we just want to check the current release version, this simplifies things quite a lot and I don't mind making that change at all (it means we don't have to pass any properties in to jalview to suggest a different appbase etc).