Bugs item #1680161, was opened at 2007-03-13 16:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1680161&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: molvisions (molvisions)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNA keyword not recognized
Initial Comment:
hi,
in playing around with the new translucency in 11.1.20, I noticed that
select nucleic
works as expected, but
select dna
does not select any atoms. I am working with the pdb file 1A1L from the PDB.
tim
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1680161&group_id=23629

Obviously the glass is half full or the glass is half empty. For now,
I'm implemented this as
translucent 0.0 == "opaque"
I figure that in the future, if we want opacity, we can add
opaque 0.0 == "transparent"
(But of course, we already have "opaque 0.0" -- it's called "hide").
Angel Herraez wrote:
>El 13 Mar 2007 a las 0:42, Miguel escribió:
>
>
>>However, I recommend that the script commands support a floating point
>>range. 0.0 being transparent and 1.0 being opaque.
>>
>>
>
>I'm naive at this business, but if it's called translucency I would
>expect to have 0.0 = opaque and 1.0 = transparent
>
>Or else the new ability should be called "opacity"?
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Jmol-developers mailing list
>Jmol-developers@...
>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>

El 13 Mar 2007 a las 0:42, Miguel escribi=F3:
> However, I recommend that the script commands support a floating point
> range. 0.0 being transparent and 1.0 being opaque.
I'm naive at this business, but if it's called translucency I would
expect to have 0.0 =3D opaque and 1.0 =3D transparent
Or else the new ability should be called "opacity"?

Ah, I found the bug with the banding. This is fixed. Oh, I do like this
translucency.
Miguel suggested changing the scale, and I have done so. You can specify
translucency
either in integer format (2-255) or as a float (0-1). "0" is still "Jmol
10.2"-style,
since we have "opaque" to cover that. Only three levels are really
implemented. The
cutoffs are 128, 192, and 224 (0.5, 0.75, and 0.825).
Bob

> Jmol developers.
>
> Correction -- bug found in Triangle renderer -- no more stray lines.
> Planes are clean; isosurfaces are smooth. Please thank Jeff Tseng and
> Miguel Howard for working with me on this. That last bug was a doozy.
> VERY TRICKY!!!
Excellent!
> You have to check out the halos. Truly ethereal.
Halos are *very* nice :-)
Miguel

> Just checked in, Jmol 11.1.21 will test a new translucency option. I
> still have to check all the shapes, but basically the way it works is
> that you specify "translucent n" instead of "translucent", where n can
> be 0 to 3.
I am certainly in favor of only supporting a finite number of levels.
However, I recommend that the script commands support a floating point
range. 0.0 being transparent and 1.0 being opaque.
I don't feel the need to support integers, but if we did so then we should
use 0-255 ... a direct mapping of the alpha channel.
In both cases, we would map to one of our finite values internally.
That way, down the road we can maintain script compatibility when better
graphics hardware is ubiquitous and someone ports to OpenGL ... say, 10
years from now :-)
Miguel

Jmol developers.
Correction -- bug found in Triangle renderer -- no more stray lines.
Planes are clean; isosurfaces are smooth. Please thank Jeff Tseng and
Miguel Howard for working with me on this. That last bug was a doozy.
VERY TRICKY!!! In any case, it's fixed now, and we have some pretty nice
translucency. We do see some digital banding/interference (sp?) effects
when the back side of a surface interacts with the front side, but I'm
not certain exactly where that is coming from. This is removed if
slabbing is on, and we could add an option that removes the back parts
of isosurfaces, but it's so neat with them there that at least for now I
don't want to remove it. Hey, this is the first time we've seen the BACK
side of any translucent object!
You have to check out the halos. Truly ethereal.
Comments and suggestions appreciated.
Bob
11.1.21
Introduces "real" color translucency
color xxxx translucent N
where N is 0 to 3.
translucent 0 same as Jmol 10.2
translucent 1 1/2 translucency (default)
translucent 2 3/4 translucency
translucent 3 7/8 translucency (very sheer)
Bob Hanson wrote:
> The effect for planes and isosurfaces is, as we say in Minnesota,
> "interesting." Some will like it; some won't. The effect is that you
> see a hint of a "mesh" included even if you do not ask for one. Now,
> the reason this is "interesting" is that in some ways is really nice
> -- I personally think you get a much better sense of the curvature of
> a surface and the angle of a plane, but others may feel it detracts.
> But it's not perfectly smooth.
>
> This is experimental. The design is such that if you use translucency
> 1-3, then the amount of memory allocated to construct the image is
> doubled, but if you have no translucent objects, then there is no
> additional memory allocated, and there may even be some efficiencies
> introduced because I cleaned up some of the methods.
>
> Comments appreciated once this gets released.
>
>
>
>
>
>
>
>
>
> Halos are
> Wait till you see halos!!! Ooooh. And just for kicks, I made the Jmol
> frank translucent 1.
>
> If we wanted to, then, we could specify
>
> color translucency n
>
> For example:
>
>
>
> Miguel wrote:
>
>>> sorry. Forgot to build; had an extra semicolon.
>>>
>>
>>
>> no problem ... pulling down now
>>
>>
>>
>>> OK, here is the situation:
>>>
>>> I think this translucency is going to work. It has a great feel to it,
>>> and with two translucent objects it is
>>> excellent. It seems to suffer -- or have the feature -- of
>>> showing the triangles a bit -- sort of a bright line around each
>>> triangle. My analysis is that
>>> it is due to multiple writes to the pbuffer along a given line.
>>>
>>
>>
>> I think that you are exactly right. When two triangles come together the
>> edges get written twice. I was trying to ensure that there was no
>> 'cracking' that occurred in solid surfaces. In the opaque world it
>> did not
>> make any difference ... The story wasy "better safe than sorry".
>>
>>
>>
>>> Unless
>>> we have a way around that,
>>> you get a brightening due to the multiple layering.
>>>
>>
>>
>> You may already be doing this in the code, but here is an idea.
>>
>> If the pixel is translucent *and* its ARGB value == the current tbuf
>> (translucent buffer) ARGB value, then drop the pixel ... don't mix it
>> with
>> the pbuf
>>
>> As I write this I am thinking that this problem may start to show up in
>> other places.
>>
>>
>>
>>> So:
>>>
>>> 1) This is a cool feature and we should keep it, or
>>> 2) We need to get rid of it.
>>> 3) We introduce it this way anyway and try to fix it later.
>>>
>>> I'm stuck on this one. Miguel, maybe you have an idea what is going on.
>>>
>>
>>
>> As I said, I think that you are right.
>>
>> I know that there were places where I was explicitly drawing more than
>> once. When two triangles were being drawn side-by-side there were times
>> when a pixel or two between them would not get filled in. This
>> fence-condition "cracking" is always a problem in the graphics world,
>> especially if you are doing everything in integers ... as we are. (An
>> interesting historical note, the original 1984 Macintosh graphics system
>> placed the coordinates *between* the pixels instead of *on* the
>> pixels in
>> order to minimize/avoid this problem. They probably still have this
>> model.)
>>
>> Not sure what the solution is, other than to discard duplicate pixels.
>> Even so, I suspect that there will still be some problems because there
>> will be cases where the z-depth value will be off by 1.
>>
>>
>> I'll take a look at the build.
>>
>> Q: What easy script can I run that best shows the problem?
>>
>>
>> Miguel
>>
>>
>
>

Just checked in, Jmol 11.1.21 will test a new translucency option. I
still have to check all the shapes, but basically the way it works is
that you specify "translucent n" instead of "translucent", where n can
be 0 to 3.
color atoms translucent 1
isosurface variable charge translucent 2
isosurface plane {1 1 1 0} translucent 3 yellow
The higher the number, the weaker the image -- the more translucent the
object. This new translucency model uses "standard" translucent color
additivity -- translucent objects both "emit" their color and "blend" in
with the objects behind them so as to change those objects' color.
Obscured objects can be translucent themselves. The model supports up to
two translucent objects in front of an opaque one. If THREE translucent
objects are in line, then the rear two translucent objects -- the two
being "hidden" by the front one -- are not guaranteed to appear in the
correct color-order. (You will see both, but you will not see when one
goes behind the other.)
Right now I have "translucent 1" being the default -- the same as
"translucent" by itself, and a relatively strong image. Jmol 10-type
translucency is "translucent 0", and you can change the default
translucency with
set defaultTranslucent [0 - 3]
So if you don't like this at all, use
set defaultTranslucent 0
and you will have what you have always had.
The effect with halos (I think) is outstanding. The effect with
spacefill and wireframe is intriguing though probably not particularly
valuable. The effect with cartoons, especially with hermiteLevel=5 is
something to behold. The effect with rockets is very cool --- you see
interior dividers, one per amino acid residue.
The effect for planes and isosurfaces is, as we say in Minnesota,
"interesting." Some will like it; some won't. The effect is that you see
a hint of a "mesh" included even if you do not ask for one. Now, the
reason this is "interesting" is that in some ways is really nice -- I
personally think you get a much better sense of the curvature of a
surface and the angle of a plane, but others may feel it detracts. But
it's not perfectly smooth.
This is experimental. The design is such that if you use translucency
1-3, then the amount of memory allocated to construct the image is
doubled, but if you have no translucent objects, then there is no
additional memory allocated, and there may even be some efficiencies
introduced because I cleaned up some of the methods.
Comments appreciated once this gets released.
Halos are
Wait till you see halos!!! Ooooh. And just for kicks, I made the Jmol
frank translucent 1.
If we wanted to, then, we could specify
color translucency n
For example:
Miguel wrote:
>>sorry. Forgot to build; had an extra semicolon.
>>
>>
>
>no problem ... pulling down now
>
>
>
>>OK, here is the situation:
>>
>>I think this translucency is going to work. It has a great feel to it,
>>and with two translucent objects it is
>>excellent. It seems to suffer -- or have the feature -- of
>>showing the triangles a bit -- sort of a bright line around each
>>triangle. My analysis is that
>>it is due to multiple writes to the pbuffer along a given line.
>>
>>
>
>I think that you are exactly right. When two triangles come together the
>edges get written twice. I was trying to ensure that there was no
>'cracking' that occurred in solid surfaces. In the opaque world it did not
>make any difference ... The story wasy "better safe than sorry".
>
>
>
>>Unless
>>we have a way around that,
>>you get a brightening due to the multiple layering.
>>
>>
>
>You may already be doing this in the code, but here is an idea.
>
>If the pixel is translucent *and* its ARGB value == the current tbuf
>(translucent buffer) ARGB value, then drop the pixel ... don't mix it with
>the pbuf
>
>As I write this I am thinking that this problem may start to show up in
>other places.
>
>
>
>>So:
>>
>>1) This is a cool feature and we should keep it, or
>>2) We need to get rid of it.
>>3) We introduce it this way anyway and try to fix it later.
>>
>>I'm stuck on this one. Miguel, maybe you have an idea what is going on.
>>
>>
>
>As I said, I think that you are right.
>
>I know that there were places where I was explicitly drawing more than
>once. When two triangles were being drawn side-by-side there were times
>when a pixel or two between them would not get filled in. This
>fence-condition "cracking" is always a problem in the graphics world,
>especially if you are doing everything in integers ... as we are. (An
>interesting historical note, the original 1984 Macintosh graphics system
>placed the coordinates *between* the pixels instead of *on* the pixels in
>order to minimize/avoid this problem. They probably still have this
>model.)
>
>Not sure what the solution is, other than to discard duplicate pixels.
>Even so, I suspect that there will still be some problems because there
>will be cases where the z-depth value will be off by 1.
>
>
>I'll take a look at the build.
>
>Q: What easy script can I run that best shows the problem?
>
>
>Miguel
>
>

Jmol developers.
I needed to check in some code that is not up to standards -- it is most
of the way through a new means of displaying translucent objects, but it
is largely unchecked and has known bugs. Please don't check it out
unless this is particularly what you are interested in. I will work on
it more tonight and possibly revert the whole thing.
Bob

hi all,
I just fired up the Jmol application (v11.1.20 on OS X) and noticed that
cartoon on
displays 1D cartoons with no thickness, very similar to ribbons,
instead of the usual 3D cartoons. is this an intentional change? if
so, how do I display the old-style cartoons?
thanks,
tim
--
Timothy Driscoll em: molvis@...
Virginia Bioinformatics Institute ph: 540-231-3007
Bioinformatics I: M-1 im: molvisions
Washington St., Blacksburg, VA 24061

>
>
>plus the article quotes Henry Rzepa, which means it must be on-topic
>as well as authoritative. :-)
>
It simply means I had an opportunity to send the message that
comparing 3D coordinates needed availability of such!
There is a sensible question I could pose here (or to the developers).
How easily could a robot of any kind "detect" Jmol coordinates?
It would have to parse the load entry in the script line, and that line I suppose is
parsable using a suitable regex expression. Another, more explicit
way of identifying a molecule is to use a "handle", ie
http://dx.doi.org/10042/to-116, which like the prefix implies, is similar
to a DOI, and one name for which could be a COI (that is still being
discussed).
So my question would be; to assist in robotic discovery, how best
could one incorporate any such object identifier in the Jmol
invocation? Or,more generally, should there (is there?) any
explicit metadata declared to assist robotic harvesting?
The "COI" by the way derives from a Cambridge/Imperial digital
repository project.
--
Henry Rzepa.
+44 (020) 7594 5774 (Voice); +44 (0870) 132 3747 (eFax); rzepahs@... (iChat)
http://www.ch.ic.ac.uk/rzepa/ Dept. Chemistry, Imperial College London, SW7 2AZ, UK.
(Voracious anti-spam filter in operation for received email.
If expected reply not received, please phone/fax).

Feature Requests item #1676604, was opened at 2007-03-08 15:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379136&aid=1676604&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: friedar (friedar)
Assigned to: Nobody/Anonymous (nobody)
Summary: zoomTo, moveTo improvement
Initial Comment:
It would be great if zoomTo and moveTo would
1 - check to see if they are already in the desired position before taking the time to make the move. IOW, if they are already at the desired zoom and center (for zoomTo) or already at the desired orientation etc. (for moveTo), then the command would be ignored. This would prevent the delay that currently occurs when a script calls for a smooth transition to a position that the molecule currently is in.
2- check to see if spin is on; if it is, stop spin, execute the command, and then resume the spin. An example of what happens currently with spin on when a zoomTo command is issued can be seen at:
http://moleculesinmotion.com/eric_jmol_tutorials/hemoglobin/hbsstruc.htm
by clicking on any button twice in a row. You will see that the structure wiggles around - this is because it is already at the desired zoom level. To see why I build in the zoomTo command, click any of buttons 1-4, then click any of buttons 5-8, or 10. The zoomTo is really meant for the transitions between those two groups of buttons, but leads to wiggling if you click the buttons in the same group consecutively.
To see the desired effect, click any of 5-8, then click 9 - an instant transition, no hesitation, no wiggling. (This script is not a solution to the problem - it has no zoomTo, so if it is clicked after any of buttons 1-4, the structure remains too zoomed out).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379136&aid=1676604&group_id=23629

Bugs item #1674533, was opened at 2007-03-05 20:38
Message generated for change (Comment added) made by ceroni
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scripting
Group: v11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ceroni (ceroni)
Assigned to: Miguel (migueljmol)
Summary: trouble with ECHO command
Initial Comment:
I'm trying to use the ECHO command to just warn users that the molecule loading can take a while. I've figure out that it isn't possible to use ECHO before loading any pdb file, so I'm using a dummy file whith just one H atom.
I've tried this without success (the ECHO never appears):
jmolApplet(550, "load dummy.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"; load 1JVEmod.pdb; spacefill off");
This one works sometimes (the ECHO and the molecule appears, only the ECHO, only the molecule):
jmolApplet(550, "load 1atom.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"");
jmolScript("load 1JVEmod.pdb; spacefill off");
Am I doing something wrong or is this a bug?
----------------------------------------------------------------------
>Comment By: ceroni (ceroni)
Date: 2007-03-07 11:52
Message:
Logged In: YES
user_id=1493510
Originator: YES
Had a relative success using:
jmolApplet(550, "script warn.txt; load 1JVEmod.pdb; spacefill off");
warn.txt:
zap;
set echo middle center;
font echo 20 sanserif bold;
color echo white;
echo Loading...;
delay 0.1;
Even so, it doesn't work every time the page is loaded. It's a very odd
behaviour. Sometimes the message just flashes, some other times it doesn't
appear at all. A few times the molecule doesn't load.
----------------------------------------------------------------------
Comment By: ceroni (ceroni)
Date: 2007-03-06 17:32
Message:
Logged In: YES
user_id=1493510
Originator: YES
Thanks for the replies. A few comments:
> recent versions of Jmol allow echo tu be used without any model
loaded...
> For the initial message, you don't need a dummy model...
The only way I could get it to work was by loading a dummy model first.
Zap doesn't work. Used 10.0.1 and 10.1.7
> what takes most time ususally is loading the applet, not loading the
model...
True if you are not loading 50S subunit over a slow link!
> When you use jmolScript, probably you raise two threads and either one
can go faster and step over the other...
That seems to be the case. It explains why I'm getting different results
every time I reload
> If the delay is truly caused by loading a large structure file, it IS
nice to provide some feedback
Great! How difficult would be to have built in to the applet a simple
message like "loading model...", automatically displayed after the applet
is loaded and before the model is shown?
----------------------------------------------------------------------
Comment By: Dean Johnston (deanjohnston)
Date: 2007-03-06 14:06
Message:
Logged In: YES
user_id=1145454
Originator: NO
Angel, your comments are right on - any information about load time has to
be given before loading or outside of Jmol. If the delay is truly caused
by loading a large structure file, it IS nice to provide some feedback. I
use the Javascript setInterval() function to periodically update a message
to the user. Then I use jmolSetCallback() to cancel the message once the
molecule is loaded. It works something like this:
setMoleculeUnloaded(); // set a flag showing no molecule is loaded
(molecule.loaded = false)
jmolSetCallback("loadStructCallback", "setMoleculeLoaded"); // once the
molecule loads, set the molecule.loaded flag to true
var intervalID = setInterval(showLoadProgress, 250, intervalID); //
periodically call showLoadProgress()
/* the showLoadProgress() function removes the message and calls
clearInterval() once the molecule is loaded */
(whatever code is used to load large molecule)
Dean
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2007-03-06 03:52
Message:
Logged In: YES
user_id=1065324
Originator: NO
Hello Sérgio
First, recent versions of Jmol allow echo tu be used without any model
loaded.
Second, what takes most time ususally is loading the applet, not loading
the model, so it's probable that you don't see the message because as soon
as the dummy model is loaded, the second one is too.
When you use jmolScript, probably you raise two threads and either one can
go faster and step over the other.
In summary:
1) There is nothing you can do to warn that the initial loading will have
some delay (other than advising it in the web page, not inside Jmol)
2) If the model is large, or it comes from a slower server, you can put a
warning that will disappear when the model arrives (although I think some
times I have seen a black Jmol in between). You may want to take a look at
what eric Martz has done in FirstGlance in Jmol (model files are retrieved
from PDB and there is a previous warning).
3) For the initial message, you don't need a dummy model; you can simply
use
jmolApplet(550, "zap; set echo middle center;
echo \"Loading molecule|Please wait...||This can take a while\"; load
1JVEmod.pdb; spacefill off");
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629

Bugs item #1674533, was opened at 2007-03-05 20:38
Message generated for change (Comment added) made by ceroni
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scripting
Group: v11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ceroni (ceroni)
Assigned to: Miguel (migueljmol)
Summary: trouble with ECHO command
Initial Comment:
I'm trying to use the ECHO command to just warn users that the molecule loading can take a while. I've figure out that it isn't possible to use ECHO before loading any pdb file, so I'm using a dummy file whith just one H atom.
I've tried this without success (the ECHO never appears):
jmolApplet(550, "load dummy.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"; load 1JVEmod.pdb; spacefill off");
This one works sometimes (the ECHO and the molecule appears, only the ECHO, only the molecule):
jmolApplet(550, "load 1atom.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"");
jmolScript("load 1JVEmod.pdb; spacefill off");
Am I doing something wrong or is this a bug?
----------------------------------------------------------------------
>Comment By: ceroni (ceroni)
Date: 2007-03-06 17:32
Message:
Logged In: YES
user_id=1493510
Originator: YES
Thanks for the replies. A few comments:
> recent versions of Jmol allow echo tu be used without any model
loaded...
> For the initial message, you don't need a dummy model...
The only way I could get it to work was by loading a dummy model first.
Zap doesn't work. Used 10.0.1 and 10.1.7
> what takes most time ususally is loading the applet, not loading the
model...
True if you are not loading 50S subunit over a slow link!
> When you use jmolScript, probably you raise two threads and either one
can go faster and step over the other...
That seems to be the case. It explains why I'm getting different results
every time I reload
> If the delay is truly caused by loading a large structure file, it IS
nice to provide some feedback
Great! How difficult would be to have built in to the applet a simple
message like "loading model...", automatically displayed after the applet
is loaded and before the model is shown?
----------------------------------------------------------------------
Comment By: Dean Johnston (deanjohnston)
Date: 2007-03-06 14:06
Message:
Logged In: YES
user_id=1145454
Originator: NO
Angel, your comments are right on - any information about load time has to
be given before loading or outside of Jmol. If the delay is truly caused
by loading a large structure file, it IS nice to provide some feedback. I
use the Javascript setInterval() function to periodically update a message
to the user. Then I use jmolSetCallback() to cancel the message once the
molecule is loaded. It works something like this:
setMoleculeUnloaded(); // set a flag showing no molecule is loaded
(molecule.loaded = false)
jmolSetCallback("loadStructCallback", "setMoleculeLoaded"); // once the
molecule loads, set the molecule.loaded flag to true
var intervalID = setInterval(showLoadProgress, 250, intervalID); //
periodically call showLoadProgress()
/* the showLoadProgress() function removes the message and calls
clearInterval() once the molecule is loaded */
(whatever code is used to load large molecule)
Dean
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2007-03-06 03:52
Message:
Logged In: YES
user_id=1065324
Originator: NO
Hello Sérgio
First, recent versions of Jmol allow echo tu be used without any model
loaded.
Second, what takes most time ususally is loading the applet, not loading
the model, so it's probable that you don't see the message because as soon
as the dummy model is loaded, the second one is too.
When you use jmolScript, probably you raise two threads and either one can
go faster and step over the other.
In summary:
1) There is nothing you can do to warn that the initial loading will have
some delay (other than advising it in the web page, not inside Jmol)
2) If the model is large, or it comes from a slower server, you can put a
warning that will disappear when the model arrives (although I think some
times I have seen a black Jmol in between). You may want to take a look at
what eric Martz has done in FirstGlance in Jmol (model files are retrieved
from PDB and there is a previous warning).
3) For the initial message, you don't need a dummy model; you can simply
use
jmolApplet(550, "zap; set echo middle center;
echo \"Loading molecule|Please wait...||This can take a while\"; load
1JVEmod.pdb; spacefill off");
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629

Bugs item #1674533, was opened at 2007-03-05 19:38
Message generated for change (Comment added) made by deanjohnston
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scripting
Group: v11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ceroni (ceroni)
Assigned to: Miguel (migueljmol)
Summary: trouble with ECHO command
Initial Comment:
I'm trying to use the ECHO command to just warn users that the molecule loading can take a while. I've figure out that it isn't possible to use ECHO before loading any pdb file, so I'm using a dummy file whith just one H atom.
I've tried this without success (the ECHO never appears):
jmolApplet(550, "load dummy.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"; load 1JVEmod.pdb; spacefill off");
This one works sometimes (the ECHO and the molecule appears, only the ECHO, only the molecule):
jmolApplet(550, "load 1atom.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"");
jmolScript("load 1JVEmod.pdb; spacefill off");
Am I doing something wrong or is this a bug?
----------------------------------------------------------------------
Comment By: Dean Johnston (deanjohnston)
Date: 2007-03-06 13:06
Message:
Logged In: YES
user_id=1145454
Originator: NO
Angel, your comments are right on - any information about load time has to
be given before loading or outside of Jmol. If the delay is truly caused
by loading a large structure file, it IS nice to provide some feedback. I
use the Javascript setInterval() function to periodically update a message
to the user. Then I use jmolSetCallback() to cancel the message once the
molecule is loaded. It works something like this:
setMoleculeUnloaded(); // set a flag showing no molecule is loaded
(molecule.loaded = false)
jmolSetCallback("loadStructCallback", "setMoleculeLoaded"); // once the
molecule loads, set the molecule.loaded flag to true
var intervalID = setInterval(showLoadProgress, 250, intervalID); //
periodically call showLoadProgress()
/* the showLoadProgress() function removes the message and calls
clearInterval() once the molecule is loaded */
(whatever code is used to load large molecule)
Dean
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2007-03-06 02:52
Message:
Logged In: YES
user_id=1065324
Originator: NO
Hello Sérgio
First, recent versions of Jmol allow echo tu be used without any model
loaded.
Second, what takes most time ususally is loading the applet, not loading
the model, so it's probable that you don't see the message because as soon
as the dummy model is loaded, the second one is too.
When you use jmolScript, probably you raise two threads and either one can
go faster and step over the other.
In summary:
1) There is nothing you can do to warn that the initial loading will have
some delay (other than advising it in the web page, not inside Jmol)
2) If the model is large, or it comes from a slower server, you can put a
warning that will disappear when the model arrives (although I think some
times I have seen a black Jmol in between). You may want to take a look at
what eric Martz has done in FirstGlance in Jmol (model files are retrieved
from PDB and there is a previous warning).
3) For the initial message, you don't need a dummy model; you can simply
use
jmolApplet(550, "zap; set echo middle center;
echo \"Loading molecule|Please wait...||This can take a while\"; load
1JVEmod.pdb; spacefill off");
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629

Bugs item #1674533, was opened at 2007-03-06 01:38
Message generated for change (Comment added) made by aherraez
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scripting
Group: v11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ceroni (ceroni)
Assigned to: Miguel (migueljmol)
Summary: trouble with ECHO command
Initial Comment:
I'm trying to use the ECHO command to just warn users that the molecule loading can take a while. I've figure out that it isn't possible to use ECHO before loading any pdb file, so I'm using a dummy file whith just one H atom.
I've tried this without success (the ECHO never appears):
jmolApplet(550, "load dummy.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"; load 1JVEmod.pdb; spacefill off");
This one works sometimes (the ECHO and the molecule appears, only the ECHO, only the molecule):
jmolApplet(550, "load 1atom.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"");
jmolScript("load 1JVEmod.pdb; spacefill off");
Am I doing something wrong or is this a bug?
----------------------------------------------------------------------
Comment By: Angel Herraez (aherraez)
Date: 2007-03-06 08:52
Message:
Logged In: YES
user_id=1065324
Originator: NO
Hello Sérgio
First, recent versions of Jmol allow echo tu be used without any model
loaded.
Second, what takes most time ususally is loading the applet, not loading
the model, so it's probable that you don't see the message because as soon
as the dummy model is loaded, the second one is too.
When you use jmolScript, probably you raise two threads and either one can
go faster and step over the other.
In summary:
1) There is nothing you can do to warn that the initial loading will have
some delay (other than advising it in the web page, not inside Jmol)
2) If the model is large, or it comes from a slower server, you can put a
warning that will disappear when the model arrives (although I think some
times I have seen a black Jmol in between). You may want to take a look at
what eric Martz has done in FirstGlance in Jmol (model files are retrieved
from PDB and there is a previous warning).
3) For the initial message, you don't need a dummy model; you can simply
use
jmolApplet(550, "zap; set echo middle center;
echo \"Loading molecule|Please wait...||This can take a while\"; load
1JVEmod.pdb; spacefill off");
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629

Bugs item #1674533, was opened at 2007-03-05 20:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Scripting
Group: v11
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ceroni (ceroni)
Assigned to: Miguel (migueljmol)
Summary: trouble with ECHO command
Initial Comment:
I'm trying to use the ECHO command to just warn users that the molecule loading can take a while. I've figure out that it isn't possible to use ECHO before loading any pdb file, so I'm using a dummy file whith just one H atom.
I've tried this without success (the ECHO never appears):
jmolApplet(550, "load dummy.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"; load 1JVEmod.pdb; spacefill off");
This one works sometimes (the ECHO and the molecule appears, only the ECHO, only the molecule):
jmolApplet(550, "load 1atom.pdb; spacefill off; set echo middle center; echo \"Loading molecule|Please wait...||This can take a while\"");
jmolScript("load 1JVEmod.pdb; spacefill off");
Am I doing something wrong or is this a bug?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=379133&aid=1674533&group_id=23629

Bob Hanson wrote:
> Ah -- interesting. Only the CSS method works with Opera 8.55. From a
> Jmol point of view there is no reason not to resize -- the code is all
> set up for it, and it is done all the time as standard operation with
> the application. I think we can provisionally recommend the CSS method.
> Lots of interesting possibilities there. Note that the
> getProperty("image") method then gets you a much higher resolution shot,
> and you can do the resize just temporarily, get the image, and then
> resize back if you wanted.
>
>
I tried to implement this as a "snapshot" button (Jmol 11.1.9):
1) resize applet to maximum (2000x2000)
2) jmolGetPropertyAsString("image")
3) resize applet back to default size (600x600)
Unfortunately it didn't work. The snapshot was done with 600x600 pixels.
It looks like a timing problem. If I separate resizing and snapshot into
two buttons the snapshot is done with 2000x2000 pixels.
But there is still another problem. After resizing back to 600x600 pixel
the view isn't adapted to the new applet size. In the application the
adaptation is done as expected (and required, I would say).
Regards,
Rolf

>>I've always avoided dynamic resizing of Jmol applets due to "official"
>> advice in Jmol webpage
>>(Miguel's, I guess), but this is an interesting subject. I like dynamic
>> sizes.
This is my recollection ... perhaps faulty impressions ...
The issues I observed were related to issues that occurred during the
stretching operation.
As the browser window was dragged there were a large number of 'resize'
events that queued up. My impression was that the browsers and/or
JmolApplet would choke when they received such a large number of resize
events. I had the impression that there were problems with reentrant code,
either on one side or the other.
These issues may have gone away with new releases of browsers over the years.
If there are still issues on some browsers then perhaps it would be worth
setting a timer so that JmolApplet doesn't repaint until 0.5 seconds after
a resize event ... or something like that. Basically, don't try to keep up
during the stretching operation. Minimize computation until things settle
down on the new size.
Miguel

Jmol 11.1.17 is ready for distribution, Nico. I need to take off my Jmol
hat for a while now and let this shake out. This latest check-in
involved a new idea -- "registering" global variable names. This allows
them to be used anywhere a variable would be used.
I got terribly bogged down yesterday in trying to get the global
variable businees right. If someone wants to look into that and tell me
if I'm on the right track, feel free. Here's the situation:
We have a class GlobalSettings that contains a number of, well, global
settings. These are settings that persist between file loads (mostly).
Strictly speaking, then persist until the next "initialize" command. The
complications are not easy:
-- Some settings (SET ...) get saved only in shape objects such as Strands.
-- Some settings can be made muliple ways -- through JmolAdapter public
methods, by
using SET xxx ..., or by some other command, such as "vector scale x.x".
What I've tried to do is make it so that as much as possible, all SET
commands operate through one of the viewer methods:
setBooleanProperty()
setIntProperty()
setFloatProperty()
setStringProperty()
The reason for this is that then they automatically get saved in the
global hash table for variables (viewer.global.htPropertyFlags for
booleans; viewer.global.htParameterValues for the others).
All SET variables are now available on the left-hand side of an assignment:
set bondMode or
bondMode = OR
etc. This is a simple compiler change that just turns "xxxx =" into "set
xxxx" in all cases. So you can do some arguably strange things like:
echo = top left
echo "this is an echo"
What this means in practice is that SET is no longer necessary. Once a
variable is "registered" in one of those tables (which all 80+ SET
keywords are now) it becomes available on the right-hand side of an
assignment as well, and in IF statements:
if (showBoundbox) ....
My problem was and still is that some SET commands go straight to the
shape objects themselves and store the variable there. This results in
the variable becoming volatile -- when a file is loaded, all shape
objects are flushed. So they never become actual state variables. I
don't know exactly what the solution is for that.
Where I'm leaving this is that now at least we have a full list of all
the possible variables that can be set. See
http://www.stolaf.edu/academics/chemapps/jmol/docs/?ver=11.1#table1 If
my count is right, I count 122 such variables. I realize that some are
not documented. I have to leave it at that for now; most of the
undocumented ones can be figured out from their name, I think.
Anyway, this is where I'm leaving it for now. Let's see how it goes.
Some are quite interesting. For example:
stereo on
stereoDegrees = 5
stereoDegrees = -5
etc.
And I see that the list needs checking. For example, it seems to suggest
you should be able to do:
x = frank;
but you cannot do that. So that needs some work. I think all it is is
that Jmol is failing to check known token words like "frank" and
"history" as variables.
Bob

Ah -- interesting. Only the CSS method works with Opera 8.55. From a
Jmol point of view there is no reason not to resize -- the code is all
set up for it, and it is done all the time as standard operation with
the application. I think we can provisionally recommend the CSS method.
Lots of interesting possibilities there. Note that the
getProperty("image") method then gets you a much higher resolution shot,
and you can do the resize just temporarily, get the image, and then
resize back if you wanted.
Bob
Angel Herraez wrote:
>I've always avoided dynamic resizing of Jmol applets due to "official" advice in Jmol webpage
>(Miguel's, I guess), but this is an interesting subject. I like dynamic sizes.
>
>I have tested this:
>
><script type="text/javascript">
>function resize(n)
>{
> document.getElementById("jmolApplet0").width = n
> document.getElementById("jmolApplet0").height = n
>}
>function resizeCSS(n)
>{
> document.getElementById("jmolApplet0").style.width = n+"px"
> document.getElementById("jmolApplet0").style.height = n+"px"
>}
></script>
>
><form>
><input type="text" name="v">
><input type="button" value="resize" onClick="resize(this.form.v.value)">
><input type="button" value="resize CSS" onClick="resizeCSS(this.form.v.value)">
></form>
>
>Both methods work fine in Firefox 1.5, IE 7 and Opera 9.02 (all WinXP)
>
>I haven't tried resizing the window as you, but your code should be doing something similar to
>my functions, right? Maybe what fails is window resize detection, not applet resizing.
>
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Jmol-developers mailing list
>Jmol-developers@...
>https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
>

Egon Willighagen wrote:
>On Friday 02 March 2007, Bob Hanson wrote:
>
>
>>Q: Is this a good idea?
>>
>>
>
>I find 600+ still quite large... but a 42% reduction is not bad.
>
>How does this, however, relate to the indexing? This indexing allows browsers
>to download just those JmolX.jar jars which are needed for the
>functionality... So, when using that set of jars instead of the singular
>Jmol.jar, then people would not even download 600k, or ... ?
>
>
>
My check with my own server suggests that using "JmolApplet0.jar" and
thus setting up the multiple jar load is no great advantage -- all 7 jar
files are downloaded in quick succession, far sooner than access to
those is required. However, if the Jar files are unpacked, and class
files are present in the proper directories, then those class files are
downloaded only when needed. Perhaps I'm missing something. Does anyone
else have access to a server log? Robert Lancashire, maybe you can test
this -- on a page using an initialization specifying JmolApplet0.jar,
does your server NOT send all the jar files?
>>Q: Has the Jmol applet gotten too large?
>>
>>Q: If so, what would the different "flavors" of Jmol include?
>>
>>
>
>The indexing already provides flavours... Jmol1.jar - Jmol9.jar (or something
>like that...)
>
>
>
I'd like more evidence that this is true.
>Egon
>
>
>

Dear Jmol community,
A bit over a week from now, the deadline for registering our project with
Google's summer of code. We did not participate the last two years, but we
can this year.
There are some things to sort out, but first lets talk about the advantages.
1. any student at a university can get payed for work on our project
There are already some students working on Jmol. They can get payed for it!
4500 dollar or so! That should be a good incentive to have a student work on
something interesting for your (research) group. Even PhD students qualify,
all that is required is a proof that the student is associated with a
university!
2,etc. more attention, more people working on Jmol, etc.
OK, now what needs to be sorted out [1]:
a. we need a main organization administrator
Bob, Nico, or I could do this (or someone else...), and we need one backup.
b. mentors
The mentors are those who supervise the SoC students. Now consider that you
have a student interested in a project in your research group, which involves
Jmol code programming (*); you already supervise this student, so no new
overhead in being a mentor.
Moreover, mentoring can also be done via the internet, so basically anyone can
be mentor. Additionally, the students are expected to participate in the
Jmol community itself, so a mentor would not be at his/her own. (think
mailing lists, IRC, wiki, etc)
*. the only requirement is that all source code created gets contributed to
the project
c. projects
Some projects are already listed [2], but any project is welcome which
involves Jmol coding. There are only three project ideas listed now, so do
feel free to add more there, and if you can, with a separate wiki page with
details.
d. students
After the project has registered (and got approved), it is up to students to
apply. For this, we will need to advertise the Google SoC with students.
Students can come from any country, and I welcome anyone from anywhere to
participate in this.
Hope to year from you soon!
Egon
1.http://code.google.com/support/bin/topic.py?topic=10442
2.http://wiki.jmol.org:81/index.php/ProgrammeerZomer
--
e.willighagen@...
Cologne University Bioinformatics Center (CUBIC)
Blog: http://chem-bla-ics.blogspot.com/
GPG: 1024D/D6336BA6

On Friday 02 March 2007, Bob Hanson wrote:
> Q: Is this a good idea?
I find 600+ still quite large... but a 42% reduction is not bad.
How does this, however, relate to the indexing? This indexing allows browsers
to download just those JmolX.jar jars which are needed for the
functionality... So, when using that set of jars instead of the singular
Jmol.jar, then people would not even download 600k, or ... ?
> Q: Has the Jmol applet gotten too large?
>
> Q: If so, what would the different "flavors" of Jmol include?
The indexing already provides flavours... Jmol1.jar - Jmol9.jar (or something
like that...)
Egon
--
e.willighagen@...
Cologne University Bioinformatics Center (CUBIC)
Blog: http://chem-bla-ics.blogspot.com/
GPG: 1024D/D6336BA6