Messages_es.properties

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'task/JAL-3991_check_actual_JAVA_VERSION_against_build_properties_in_application_startup' into develop

  1. … 5 more files in changeset.
I've now put in a warn with the e.getMessage(), but I've left in a debug with the full stacktrace. This catch block is a little odd in that it's used as programmatic flow for non 200 HTTP responses...

I've now put in a warn with the e.getMessage(), but I've left in a debug with the full stacktrace.
This catch block is a little odd in that it's used as programmatic flow for non 200 HTTP responses. I notice that the new API server is sending back a 400 for bad input (including for non-existent query fields and wrong types for non-string query fields), which is invoking the warning triangle which puts the HTTP error message into the tooltip so this block is now getting more use!

The reason for wanting a full stacktrace in debug mode is that both the API and the changed client are new, so any errors in the next few months will be more quickly diagnosed if we can allow the user to easily obtain a stacktrace of the exception.

after trying it out I think the old behaviour is better, unless 1) there's a really clear message in the UI explaining that now the field has changed, the search needs to be executed again 2) a con...

after trying it out I think the old behaviour is better, unless 1) there's a really clear message in the UI explaining that now the field has changed, the search needs to be executed again 2) a convenient [search] button is shown so one doesn't have to click into the query field and press enter to trigger the search again.

should be Console.warn

should be Console.warn

Need to add logic that either 1) modifies config if an existing value of UNIPROT_DOMAIN is found that is legacy.uniprot.org or 2) uses UNIPROT_2022_DOMAIN as a config value so old versions of Jalvi...

Need to add logic that either 1) modifies config if an existing value of UNIPROT_DOMAIN is found that is legacy.uniprot.org or 2) uses UNIPROT_2022_DOMAIN as a config value so old versions of Jalview still work (up until legacy.uniprot.org goes away).

JAL-4036 Add getDbName to the GFTSPanelI and add an index code message to the index dropdown tooltip as appropriate

  1. … 6 more files in changeset.
shouldn't this be a warn ?

shouldn't this be a warn ?

this comment block should really be after the imports ?

this comment block should really be after the imports ?

makes sense. I do wonder if there needs to be some indication that any results currently shown are stale, however ?

makes sense. I do wonder if there needs to be some indication that any results currently shown are stale, however ?

JAL-4036: Jalview 2.11.2.2 and earlier no longer compatible with Uniprot REST API
JAL-4036: Jalview 2.11.2.2 and earlier no longer compatible with Uniprot REST API
JAL-4036 removed often duplicated pluralisation in message

  1. … 1 more file in changeset.
JAL-3991 JAVA_COMPILE_VERSION put into build_properties. Check for possible JVM mismatch in jalview.bin.LaunchUtils. STDERR warning from jalview.bin.Launcher. Console and optional popup warning in jalview.bin.Jalview.

  1. … 6 more files in changeset.
JAL-3851 allow multiple instances of Endpoints. Fixes to naming of IGV colour scheme

  1. … 11 more files in changeset.
JAL-3103 Remove BrowserLauncher2 and use Desktop.browse(url) with wrapper methods

  1. … 11 more files in changeset.
JAL-3103 Put jalview.jar first in getdown for .properties files. Remove now-not-needed exception handling from jalview code for openURL. Change Default browser input to JComboBox populated by BrowserLauncher2

  1. … 11 more files in changeset.
JAL-3103 Switched to (a wrapper around) BrowserLauncher2

  1. … 6 more files in changeset.
JAL-722 updated from 2.11.2 develop branch - needs further work before release

Conflicts:

resources/lang/Messages.properties

resources/lang/Messages_es.properties

src/jalview/datamodel/Alignment.java

src/jalview/gui/AlignFrame.java

src/jalview/io/AlignFile.java

src/jalview/project/Jalview2XML.java

  1. … 11 more files in changeset.
Merge branch 'bug/JAL-3633_read_proxy_settings_from_jalview_properties_in_getdown' into develop

Conflicts:

src/jalview/bin/MemorySetting.java

  1. … 8 more files in changeset.
JAL-3774 combined changes from bug/JAL-3774_splitFrameFinder: i) fixed focus Finder from split frame. ii) missing i18n added, overlong translation shortened. iii) better translation.

  1. … 4 more files in changeset.
JAL-3739 (combined) commits from feature/JAL-3739_useFormFieldText

  1. … 6 more files in changeset.
JAL-3503 Added a Startup tab in Preferences, with gui for JVMMEMMAX and JVMMEMPC settings. Allowed jalview.bin.Launcher and getdown to read/use these memory settings at launch. Added channel.props to getdown appdir, used to determing correct .jalview_properties file. Refactored MemorySetting a bit, with more helper methods for the Preferences tab.

  1. … 20 more files in changeset.
Merge branch 'feature/JAL-3692enaEndpoint' into patch/for2.11.2/JAL-3821_ena_rna_moltype

  1. … 1 more file in changeset.
JAL-3739 catch parameter errors and report to the user

  1. … 3 more files in changeset.
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 ?