Hello, I would like to ask for help with a small issue I've run into while installing Jalview on a Linux Mint (latest version) laptop for a friend of mine. Whenever I try running the install program (the one with the JVM included), I get this error: "Installer User Interface Mode Not Supported - The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The valid UI modes identifiers are GUI, Console, and Silent.". When I then use the -i GUI option, I get a similar error: "The installer is unable to run in graphical mode.". Any ideas as to what might be causing this?
18 replies
I can meet earlier if preferred
I've tested JAL-3725 (which ended up fixing the JAL-3700 problemette no. 1). There are two cases given in the first comment (of JAL-3725), and I can replicate the problem in 2.11.1.2 and see it's fixed in the patch/JAL-3700... branch. I am either not understanding the second case problem or am just unable to replicate it. Using the example given which includes a stop codon (EMBL X53828) in a 2.11.1.2 build I add some overlapping features (on either end) and then Get Cross-References UNIPROT, and the features seem to appear fine on the CDS pane. I was thinking this was what was problematical in Case 2, or am I misunderstanding? Either way, any problem goes away if the features are not transferred!
Here's the comment referred to: https://issues.jalview.org/browse/JAL-3725?focusedCommentId=24116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24116
Here's the comment referred to: https://issues.jalview.org/browse/JAL-3725?focusedCommentId=24116&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24116
2 replies
or we cross fingers and update release channel directly :^>
Terribly sorry to bother you again...we managed to install Jalview with the installer you provided and it is indeed found under /root/opt/jalview, but we can't seem to find it anywhere in the list of programs OR to be able to run it from its folder. Is there any way we can fix this?
13 replies
I'm not sure if it's a known issue (I can recall something similar was mentioned in the meeting) but when I start the aacon job and click cancel the alignment viewport stops responding to the keyboard input.
Often, it also leaves an empty progress bar which spins forever, but I already fixed this in my JAL-3690 branch.
openjdk-11.0.9 2020-10-20 on Ubuntu 18.04.1
Often, it also leaves an empty progress bar which spins forever, but I already fixed this in my JAL-3690 branch.
openjdk-11.0.9 2020-10-20 on Ubuntu 18.04.1
5 replies
Running jalviewjs from branch
feature/JAL-3690_callback-based-web-services in Chrome (doesn't start in Firefox at all) results in a following error:TypeError: Cannot read property 'apply' of undefined
TypeError: Cannot read property 'apply' of undefined
at $I$ (swingjs/j2s/jalview/workers/AlignCalcManager2.js:1:475)
at Object.eval [as getWorkers$] (swingjs/j2s/jalview/workers/AlignCalcManager2.js:25:8)
at Object.eval [as getWorkersOfClass$Class] (swingjs/j2s/jalview/workers/AlignCalcManager2.js:30:33)
at clazz.eval [as updateConservation$jalview_api_AlignmentViewPanel] (swingjs/j2s/jalview/viewmodel/AlignmentViewport.js:354:22)
at clazz.eval [as addAlignmentPanel$jalview_gui_AlignmentPanel$Z] (swingjs/j2s/jalview/gui/AlignFrame.js:333:8)
at clazz.eval [as c$$jalview_datamodel_AlignmentI$jalview_datamodel_HiddenColumns$I$I$S$S] (swingjs/j2s/jalview/gui/AlignFrame.js:43:6)
at clazz.eval [as c$$jalview_datamodel_AlignmentI$jalview_datamodel_HiddenColumns$I$I$S] (swingjs/j2s/jalview/gui/AlignFrame.js:33:76)
at clazz.eval [as c$$jalview_datamodel_AlignmentI$jalview_datamodel_HiddenColumns$I$I] (swingjs/j2s/jalview/gui/AlignFrame.js:29:74)
at clazz.eval [as c$$jalview_datamodel_AlignmentI$I$I] (swingjs/j2s/jalview/gui/AlignFrame.js:17:72)
at Object.Clazz.new_ (http://localhost:8000/swingjs/swingjs2.js:14562:19)
No hurry to answer this question about license notices in some of the source files and in relation to Debian packaging.
Pierre has noted that the JAXB generated files (jalview.xml.*) have no copyright notice. The best solution will be to put our standard Jalview copyright notice that is found at the top of the other jalview .java files. Question 1) Can I just paste these in (batch job obviously) or would it be preferable to template it into how these files were originally generated. I'm guessing the answer will be the latter (template it and re-generate) but want to check (and also that we're happy for the copyright notice to go in).
Pierre has noted that the JAXB generated files (jalview.xml.*) have no copyright notice. The best solution will be to put our standard Jalview copyright notice that is found at the top of the other jalview .java files. Question 1) Can I just paste these in (batch job obviously) or would it be preferable to template it into how these files were originally generated. I'm guessing the answer will be the latter (template it and re-generate) but want to check (and also that we're happy for the copyright notice to go in).
Question 2) The jalview/ext/android/* classes have two copyright notices. The AOSP one and the Jalview one above it. Are these sources altered from the originals?
2 replies
Random thought for the day (I suspect this must have been discussed before): Some useful Jalview functionality remains undiscovered by a lot of users. Is this because it's "hidden" in menus and submenus? Would the addition of a toolbar with buttons for more popular/useful functions/features be a useful addition for both usability and feature discovery? I'm NOT thinking Microsoft ribbon(!) but something simpler. The main downside I can think of is it takes up screen real estate.
8 replies
@BobHanson would it be possible to make the name/directory (even if relative) of the .j2s file configurable (e.g. using a property)? I guess I'm looking at line 41 of https://github.com/java2script/java2script/blob/master/sources/net.sf.j2s.core/src/net/sf/j2s/core/Java2ScriptCompiler.java
private static final String J2S_OPTIONS_FILE_NAME = ".j2s";and putting a static block in to look at property first. I could make up a PR if that would be easier?
9 replies
I've updated the develop branch with a slew of issues that went into the 2.11.1.3 release (see https://issues.jalview.org/browse/JAL-3775) along with the HTTPS and Authenticated proxy settings that didn't make it into 2.11.1.3 (see https://issues.jalview.org/browse/JAL-3633).
I've also (perhaps prematurely) added in the new utils/channels/<channelname>/... and /resources/channel.props mechanism (see https://issues.jalview.org/browse/JAL-3594) which will allow for differently configured aspects of Jalview's appearance depending on the channel set (e.g. try
gradle getdown -PCHANNEL=DEVELOP -Pgetdown_appbase_override=
java -jar ./getdown/files/11/getdown-launcher.jar ./getdown/files/11 jalview)
I've made sure this also works with JalviewJS (thanks @BobHanson for making Class.getResource() does The Right Thing!) so you can build a JalviewJS with
gradle jalviewjs -PCHANNEL=JALVIEWJS
gradle jalviewjsServer
firefox ./jalviewjsTest.html(you may need to configure
j2s.compiler.status = enable
jalviewjs_eclipse_root = ~/buildtools/eclipse/jee-2020-03in your local.properties for a headless build).
jalview.util.ChannelProperties provides a wrapper/helper for using the channel-specific items and is described in doc/building.md
ChannelProperties is the mechanism, and I've provided graphics for channels "DEVELOP", "RELEASE", "TEST-RELEASE" (not very different), "JALVIEWJS" and a default set also not very different from release. This includes the getdown splash screen and icons which are most different in DEVELOP. I'm quite pleased with the Jalview Develop splashscreen so have a go!
Pre-built Jalview Develop installers (these are bundled with the latest Java 11 runtime) can be found at http://www.jalview.org/getdown/install4j/develop/installers/11/ but these are not yet linked to from the website Development page. I'd intended to do that today but thought fixing the JalviewJS build on the develop branch was somewhat more important.
1 reply
In case anyone with a mac is thinking of upgrading their Java, the AdoptOpenJDK Java 11.0.9.1+1 JRE and JDK will not run Jalview. There appears to be some kind of error involving VAqua (so you could specify
-Dlaf=metal to use Metal Look and Feel, but ...). The 18 days older version 11.0.9+11.1 does work. I suspect this will be the case for any distribution of OpenJDK, not just the AdoptOpenJDK one.
@warownia1 spliterator issue is via https://builds.jalview.org/artifact/JB-GJB13/shared/build-4/JalviewJS-site/jalview_bin_Jalview.html?open%20https://www.jalview.org/examples/uniref50.fa
8 replies
@warownia1 Following on from your suggestion that the headless gradle build of jalviewjs would be better if it didn't alter the .j2s file (for the sake of an open Eclipse IDE also transpiling) Bob has accepted a change to java2script (now in v3.2.10) and I've made some smallish changes to build.gradle and gradle.properties to make use of this.
build.gradle should take of this when you run
If you have an existing .j2s file without
As I say, you shouldn't need to worry about that mildly complicated sounding route to an alternative .j2s file, gradle should just take care of it.
To import this into your branch, cherry-pick these two commits:
and
The first is the new swingjs folder with j2s 3.2.10 (quite a few binary files so just accept the changes!). The second are the small changes to build.gradle and gradle.properties which will hopefully be easy enough to de-conflict. Shout out if it all goes wrong, or nearly right, or, who knows, even all right!
build.gradle should take of this when you run
gradle jalviewjs but just so you know: It's a two-stage setting -- you need a normal .j2s (which is what your Eclipse IDE will be using). It needs a property j2s.config.altfileproperty set to an arbitrary string. That arbitrary string is a property name that j2s will look for when it activates in Eclipse, and the value of that property is an alternative j2s config filename.If you have an existing .j2s file without
j2s.config.altfileproperty set then gradle will add that particular property with a value "org.jalview.jalviewjsj2sfilename". When gradle runs eclipse headlessly it also sets the property "org.jalview.jalviewjsj2sfilename" to a different j2s filename (build/jalviewjs/config/j2s) which java2script in the headless Eclipse will then use.As I say, you shouldn't need to worry about that mildly complicated sounding route to an alternative .j2s file, gradle should just take care of it.
To import this into your branch, cherry-pick these two commits:
6c27b7864 JAL-3789 New swingjs for Java2Script 3.2.10 with j2s.config.altfilepropertyand
dd81c1942 JAL-3789 Use j2s.config.altfileproperty in .j2s for alternative temporary build/jalviewjs/config/j2s settings file when running a headless build in gradle.The first is the new swingjs folder with j2s 3.2.10 (quite a few binary files so just accept the changes!). The second are the small changes to build.gradle and gradle.properties which will hopefully be easy enough to de-conflict. Shout out if it all goes wrong, or nearly right, or, who knows, even all right!
1 reply
For info I'm changing my Atlassian and github/gitter emails to oldgitmungo@gmail.com, in anticipation of losing dundee.ac.uk
11 replies
@all Happy New Year. Haven't been following this closely, but thanks for submitting issues at https://github.com/BobHanson/java2script I have closed all of them as fixed. The 3.3.1-v3 transpiler is there now for Java 11, fixing an issue with final or effectively final variables in nested instances of the same superclass. The big change with 3.3.1 is full support for Java 64-bit long. It's a bit slower than integer math, but it is not bad, and it falls back to JavaScript BigInt if it is available or Java BigInteger if necessary only to handle very large long division. Everything else is handled directly in relatively simple JavaScript.
3 replies