[Jmol-users] display of contacts in two frames/models

[Angel Herráez]

It seems that the result of "contact" cannot be present separately in the two 
frames when 2 models have been loaded. Only the latest generated set of 
contacts is displayed, and only in the current frame (even if  calculated from 
atoms in the other frame).

Is there a way around? We would like to have two frames, each with its 
contacts, and switch the display  between  the 2 frames

And yes, I am specifying the atoms of only one frame when I generate the 
contacts, like:
  frame 1; contact {Leu/1}{*/1 and not Leu}
  frame 2; contact {Leu/2}{*/2 and not Leu}


Thanks,


---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Important Account Information - Reconfirm Mailing List Subscriptions

[Angel Herráez]

Yes, the email looks ugly indeed.

Rather than following the link, I signed in into sf.net, went to user area and 
there was a button to renew subscriptions. So it looks perfectly authentic.


---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Important Account Information - Reconfirm Mailing List Subscriptions

[Phillip Barak]

Saw it this morning, sniffed it suspiciously, searched for it unsuccessfully on 
sourceforge itself, and then proceeded cautiously. Leads to sourceforge 
website, filling in subscription information but not asking for any add'l 
information, and then just a click to 'confirm'.


Who knows why they do this, but ok.


--Phil Barak


From: Rzepa, Henry S 
Sent: Friday, June 9, 2017 11:24:53 AM
To: jmol-users@lists.sourceforge.net
Subject: [Jmol-users] Important Account Information - Reconfirm Mailing List 
Subscriptions

This email (automatically filtered into my junk, where  I spotted it by 
accident) asks me to confirm my  jmol list memberships.  It gives a pretty good 
impression of a phishing junk email, but the link contained does look genuine.  
I presume everyone else on the jmol lists have received this?

I am vaguely surprised, if genuine, that  SF would send this sort of thing? 
Anybody spot anything that suggests the response requested should be avoided?

> Thanks for being a SourceForge user. Our records indicate that you are 
> subscribed to the following project mailing lists:
>
>jmol-developers
>jmol-users
> We are contacting you to confirm you are still interested in receiving emails 
> from these SourceForge project lists.  If you do not confirm your 
> subscriptions by June 29th, you will be unsubscribed from the above mailing 
> lists.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] Important Account Information - Reconfirm Mailing List Subscriptions

[Rzepa, Henry S]

This email (automatically filtered into my junk, where  I spotted it by 
accident) asks me to confirm my  jmol list memberships.  It gives a pretty good 
impression of a phishing junk email, but the link contained does look genuine.  
I presume everyone else on the jmol lists have received this? 

I am vaguely surprised, if genuine, that  SF would send this sort of thing? 
Anybody spot anything that suggests the response requested should be avoided?

> Thanks for being a SourceForge user. Our records indicate that you are 
> subscribed to the following project mailing lists:
> 
>jmol-developers
>jmol-users
> We are contacting you to confirm you are still interested in receiving emails 
> from these SourceForge project lists.  If you do not confirm your 
> subscriptions by June 29th, you will be unsubscribed from the above mailing 
> lists.
> 


smime.p7s
Description: S/MIME cryptographic signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Java will go from Safari as well as already gone from Opera, FF and Chrome

[Rolf Huehne]

Am 09.06.17 um 15:21 schrieb Robert Hanson:

Yes. By "felt" you mean that the browser will manage its threads
relating to tabs and other dyanamic content (e.g. ads), and it may shift
a running JavaScript app to a lower priority more likely than a running
Java application would or, in particular, then a running Java applet would.

When I tested this outside of Jmol with some Javascript it even seemed 
to me that a script run repeatedly was slowed down by the browser 
deliberately, although nothing else did change what would require to 
change the priority.


Regards,
Rolf

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

[Jmol-users] cloning part of a model into another frame

[Angel Herráez]

Dear Bob,

Is there a way to extract some residue fron the loaded model and clone or 
duplicate it in a new frame/model?

I am trying
ff1 = load('=pdbe/1foz')
load "@ff1" 

But I don't know how / if I can extract a subset of atoms from that ff1 
variable 
(and e.g. create a new model using load data). 
Is this possible?
Thanks

---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Java will go from Safari as well as already gone from Opera, FF and Chrome

[Rolf Huehne]

Am 09.06.17 um 15:21 schrieb Robert Hanson:

I think we're one level off here. You can always run Jmol.jar if you
want Jmol's desktop application, and nothing is going to change about
that. It isn't an applet, so there is no browser issue.

I don't think that Jmol's current desktop application can replace the 
applet. Besides the rich functionality and powerful scripting language 
of Jmol in general, the strength of the applet is the flexibility to 
build any interface for Jmol you want.


Take for example the Jena3D Viewer (http://jena3d.leibniz-fli.de). 
Almost nothing of it's special functionalities could be transferred to 
the current desktop application.



My quick read of the JavaFX tutorial
[docs.oracle.com/javafx/2/overview/jfxpub-overview.htm
] suggests
that it is simply a newer way to build an independent Java desktop
application like Jmol.jar, but it has a wider set of user interface
capability than what we use now (Swing). Thus, they talk about being
able to insert a full-fledged webkit browser into the application, to
use CSS for styling, to dynamically create a user interface -- that sort
of thing.

And although the general Javascript performance is catching up with
Java, my observation is that it the performance is less stable. This
means that a task for example took anything from 60 seconds to 120
seconds (or even more) in the Javascript version, depending on how
the browser 'felt'. In contrast the Java version stably needed about
ten seconds, run on the same system before and after the Javascript
version.

Yes. By "felt" you mean that the browser will manage its threads
relating to tabs and other dyanamic content (e.g. ads), and it may shift
a running JavaScript app to a lower priority more likely than a running
Java application would or, in particular, then a running Java applet would.

A 1:12 performance ratio seems on the outside of what I have observed,
but I am sure that can happen. We are seeing 1:3 to 1:6 commonly.

I'm pretty sure the real benefit would be to use the WebGL option in
JSmol, or at least to develop that further. For example, by merging
NGL's excellent 3D capabilities into JSmol.

Rolf, do you have a sense of whether these slow-downs are rendering
issues? Or do they happen in relation to file opening, model
construction, or surface construction?

Rendering speed differences are rather difficult to quantify. If I 
rotate or zoom into a large structure with many translucent bonds, it is 
rather a qualitative shift: from almost unusable to totally unusable for 
most interactive work.


My quantitative observations are related to running times of Jmol 
scripts. In the Javascript version they run up to about 50 times slower 
than in the Java version. My general impression (a few month ago) was 
that built-in functions were running about 5 times slower than in Java, 
while user-defined functions were running up to 50 times slower.


Regards,
Rolf


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Java will go from Safari as well as already gone from Opera, FF and Chrome

[Robert Hanson]

I don't know anything about JavaFX, but it's not clear to me there has
>> been any development on it since 2012 or 2014. Maybe just an idea that
>> never took off? Do you see some advantage to this?
>>
>> Since I don't have done any Java programming I will know even less. When
> I spoke to a computer scientist about the problem of dropped NPAPI plugin
> support by an increasing number of browsers, he suggested to become
> independent of any browser by combining the applet with already existing
> Java HTML5/CSS/Javascript engines. I have chosen the example engines just
> to illustrate the idea, not because I know anything particular about their
> suitability.
>
> It seems that Oracle still recommends JavaFX for Desktop applications.
> At last that is what the following post about the future of JavaFX from
> 2016 (unfortunately in German) suggests: https://jaxenter.de/hart-aber-
> fair-welche-zukunft-hat-javafx-37199 . Among other things it describes
> the reaction of Oracle to a request of an interest group of german Java
> users (iJUG) about the future of JavaFX. According to this Oracle
> recommends it and has an official roadmap for it until 2028.
>
> The advantage I see with the general idea is that each Jmol-based web
> service, running in the future with the Javascript version, could also be
> run as a Java desktop application.
>
>
I think we're one level off here. You can always run Jmol.jar if you want
Jmol's desktop application, and nothing is going to change about that. It
isn't an applet, so there is no browser issue.

My quick read of the JavaFX tutorial [
docs.oracle.com/javafx/2/overview/jfxpub-overview.htm] suggests that it is
simply a newer way to build an independent Java desktop application like
Jmol.jar, but it has a wider set of user interface capability than what we
use now (Swing). Thus, they talk about being able to insert a full-fledged
webkit browser into the application, to use CSS for styling, to dynamically
create a user interface -- that sort of thing.

And although the general Javascript performance is catching up with Java,
> my observation is that it the performance is less stable. This means that a
> task for example took anything from 60 seconds to 120 seconds (or even
> more) in the Javascript version, depending on how the browser 'felt'. In
> contrast the Java version stably needed about ten seconds, run on the same
> system before and after the Javascript version.
>
> Yes. By "felt" you mean that the browser will manage its threads relating
to tabs and other dyanamic content (e.g. ads), and it may shift a running
JavaScript app to a lower priority more likely than a running Java
application would or, in particular, then a running Java applet would.

A 1:12 performance ratio seems on the outside of what I have observed, but
I am sure that can happen. We are seeing 1:3 to 1:6 commonly.

I'm pretty sure the real benefit would be to use the WebGL option in JSmol,
or at least to develop that further. For example, by merging NGL's
excellent 3D capabilities into JSmol.

Rolf, do you have a sense of whether these slow-downs are rendering issues?
Or do they happen in relation to file opening, model construction, or
surface construction?

Bob



>
> Regards,
> Rolf
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>



-- 
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] Java will go from Safari as well as already gone from Opera, FF and Chrome

[Rolf Huehne]

Am 08.06.17 um 19:44 schrieb Robert Hanson:



On Thu, Jun 8, 2017 at 10:58 AM, Rolf Huehne mailto:rolf.hue...@leibniz-fli.de>> wrote:

Am 08.06.17 um 14:41 schrieb Robert Hanson:

RIP,  Java applets.

Since there still are many situations where the superior Java
performance would be helpful (large structures; surfaces; complex
Jmol scripts that are running about 50 times slower in the
Javascript version) it would still be good to have a Java version
with the flexibility of the applet to build customized user interfaces.

sorry, didn't mean to imply that we were dropping applet production.
It's all produced in a few clicks of a button -- Jmol app, Jmol applet,
JmolData, JSmol. So I will keep that happening the same.

I havn't misunderstood that. But an applet can only be of public use if 
there are systems available supporting it.



I am wondering how much effort it would be to extend the applet by a
HTML/CSS rendering and Javascript engine like it is provided by
systems like 'JavaFX - WebView Component
(https://docs.oracle.com/javase/8/javafx/api/toc.htm


https://stackoverflow.com/questions/2438201/pure-java-html-viewer-renderer-for-use-in-a-scrollable-pane

),
Oracle Nashorn
(http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html

),
and HtmlUnit (http://htmlunit.sourceforge.net/
).

I woud guess one of the critical points would be how much of the
Javascript/Applet communication would still be possible in such
application.


I don't know anything about JavaFX, but it's not clear to me there has
been any development on it since 2012 or 2014. Maybe just an idea that
never took off? Do you see some advantage to this?

Since I don't have done any Java programming I will know even less. When 
I spoke to a computer scientist about the problem of dropped NPAPI 
plugin support by an increasing number of browsers, he suggested to 
become independent of any browser by combining the applet with already 
existing Java HTML5/CSS/Javascript engines. I have chosen the example 
engines just to illustrate the idea, not because I know anything 
particular about their suitability.


It seems that Oracle still recommends JavaFX for Desktop applications.
At last that is what the following post about the future of JavaFX from 
2016 (unfortunately in German) suggests: 
https://jaxenter.de/hart-aber-fair-welche-zukunft-hat-javafx-37199 . 
Among other things it describes the reaction of Oracle to a request of 
an interest group of german Java users (iJUG) about the future of 
JavaFX. According to this Oracle recommends it and has an official 
roadmap for it until 2028.


The advantage I see with the general idea is that each Jmol-based web 
service, running in the future with the Javascript version, could also 
be run as a Java desktop application.


And although the general Javascript performance is catching up with 
Java, my observation is that it the performance is less stable. This 
means that a task for example took anything from 60 seconds to 120 
seconds (or even more) in the Javascript version, depending on how the 
browser 'felt'. In contrast the Java version stably needed about ten 
seconds, run on the same system before and after the Javascript version.


Regards,
Rolf

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users