From: Angel H. <ang...@ua...> - 2006-06-27 22:48:06
|
I think I've read about this, but cannot find the post. It seems (10.2) that "dots off" removes dots from all atoms, not just from the currently selected set. Is this known? Any ideas as to how to tweak it? Thanks |
From: Bob H. <ha...@st...> - 2006-06-27 23:27:20
|
This behavior, though perhaps seemingly strange, is intentional. Dots must be recalculated from scratch any time the atom set is changed so that next-neighbor overlaps can be recalculated. Thus, when any dots are turned off, all dots are turned off. I note that this behavior, though, is inconsistent -- you can turn some dots on, then more dots on, and the recalculation isn't done there. I also see there is a bug in 10.x in relation to this, so I'm interested in working on it. Make a feature request that is very specific to what you are interested in seeing, and I'll see what I can do. Bob Angel Herraez wrote: >I think I've read about this, but cannot find the post. >It seems (10.2) that "dots off" removes dots from all atoms, not just from the currently >selected set. >Is this known? Any ideas as to how to tweak it? >Thanks > > > >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Jmol-users mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-users > > |
From: Bob H. <ha...@st...> - 2006-08-28 18:16:05
|
Angel, I took a look at this, and I did make an update that at least colors dots properly. So 10.9.47 has that in it. But as I was doing that, I found that the dots ON/OFF business is a bit complicated. If we want dots OFF to work like labels and such, then it will take some reworking. There is a single "ON/OFF" flag for all dots. I like the idea of changing this to specific atoms, but we need to be sure that's what people want. Q: Anyone object to having DOTS turn on and off in response to the currently selected set of atoms? Q: When this is done, should the dot set be recalculated so that places where there was overlap with now-invisible atoms are filled in? Or should there be no additional calculation and only dots that were present before present after? Q: Should the presence of dots and no other aspect of an atom count as "visible" for that atom? That is, if: restrict 1-10; wireframe off;spacefill off; dots on; would you then expect select visible to include all residues 1-10? Bob Angel Herraez wrote: >I think I've read about this, but cannot find the post. >It seems (10.2) that "dots off" removes dots from all atoms, not just from the currently >selected set. >Is this known? Any ideas as to how to tweak it? >Thanks > > > >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Jmol-users mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-users > |
From: Rolf H. <rh...@fl...> - 2006-08-29 11:28:40
|
Bob Hanson wrote: >Angel, I took a look at this, and I did make an update that at least >colors dots properly. So 10.9.47 has that in it. But as I was doing >that, I found that the dots ON/OFF business is a bit complicated. If we >want dots OFF to work like labels and such, then it will take some >reworking. There is a single "ON/OFF" flag for all dots. I like the idea >of changing this to specific atoms, but we need to be sure that's what >people want. > >Q: Anyone object to having DOTS turn on and off in response to the >currently selected set of atoms? > > I checked different versions of Jmol (>=10.00). From 10.00 until at least 10.00.36 Jmol only switches off the dots of selected atoms, not all. This was changed somewhere between 10.00.36 to 10.00.47 (I don't have any version in between). I would expect that the 'dots' command considers the current selection and would rather like this change to be reverted. >Q: When this is done, should the dot set be recalculated so that places >where there was overlap with now-invisible atoms are filled in? Or >should there be no additional calculation and only dots that were >present before present after? > I think both options would be useful. Before you stated otherwise a few mails ago, I just took the 'dots' rendering as a kind of transparent spacefill rendering. For this purpose a recalculation would be needed. >Q: Should the presence of dots and no other aspect of an atom count as >"visible" for that atom? That is, if: > > restrict 1-10; wireframe off;spacefill off; dots on; > >would you then expect > > select visible > >to include all residues 1-10? > > > Generally I would expect any rendering type, including dots, to be considered for visibility. Maybe, if this would be easily possible, you could make the renderings that affect the visibility flag configurable by a script command. Regards, Rolf |
From: Bob H. <ha...@st...> - 2006-08-29 15:12:07
|
Rolf Huehne wrote: >Bob Hanson wrote: > > >>Angel, I took a look at this, and I did make an update that at least >>colors dots properly. So 10.9.47 has that in it. But as I was doing >>that, I found that the dots ON/OFF business is a bit complicated. If we >>want dots OFF to work like labels and such, then it will take some >>reworking. There is a single "ON/OFF" flag for all dots. I like the idea >>of changing this to specific atoms, but we need to be sure that's what >>people want. >> >>Q: Anyone object to having DOTS turn on and off in response to the >>currently selected set of atoms? >> >> >> >> >I checked different versions of Jmol (>=10.00). From 10.00 until at >least 10.00.36 Jmol only switches off the dots of selected atoms, not all. >This was changed somewhere between 10.00.36 to 10.00.47 (I don't have >any version in between). > > > OK, I was not aware of that. >I would expect that the 'dots' command considers the current selection >and would rather like this change to be reverted. > > > >>Q: When this is done, should the dot set be recalculated so that places >>where there was overlap with now-invisible atoms are filled in? Or >>should there be no additional calculation and only dots that were >>present before present after? >> >> >> >I think both options would be useful. Before you stated otherwise a few >mails ago, I just took the 'dots' rendering as a kind of transparent >spacefill rendering. For this purpose a recalculation would be needed. > > right >>Q: Should the presence of dots and no other aspect of an atom count as >>"visible" for that atom? That is, if: >> >> restrict 1-10; wireframe off;spacefill off; dots on; >> >>would you then expect >> >> select visible >> >>to include all residues 1-10? >> >> >> >> >> >Generally I would expect any rendering type, including dots, to be >considered for visibility. Maybe, if this would be easily possible, you >could make the renderings that affect the visibility flag configurable >by a script command. > > probably not the latter. That would be very complicated. But 10.9 has a new scheme for recognizing "visible" (the "visible" select option is not in 10.2), and it is generally configurable. Angel seems to agree that we need the selective dots on/off back on. probably something like dots off just turns them off dots calculate does the recalculation There may be complications with "geosurface" because "dots" and "geosurface" operate via the same code, but no one is probably going to use that option much anyway. We can deal with that later, I think. Bob >Regards, >Rolf > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Jmol-users mailing list >Jmo...@li... >https://lists.sourceforge.net/lists/listinfo/jmol-users > > |
From: Angel H. <ang...@ua...> - 2006-08-29 13:28:35
|
Bob Hanson wrote: > Q: Anyone object to having DOTS turn on and off in response to the > currently selected set of atoms? That's the behaviour I would expect. It's consistent with other renderings. > Q: When this is done, should the dot set be recalculated so that places > where there was overlap with now-invisible atoms are filled in? Or > should there be no additional calculation and only dots that were > present before present after? and Rolf Huehne wrote: > Before you stated otherwise a few > mails ago, I just took the 'dots' rendering as a kind of transparent > spacefill rendering. I thought the same. Given the recalculation step, I am not sure which option is better. To me, any ofthe two can be bearable; one can always rewrite the script to get the other. Bob Hanson wrote: > Q: Should the presence of dots and no other aspect of an atom count as > "visible" for that atom? I think yes. Thanks for all this work, Bob. |
From: Angel H. <ang...@ua...> - 2006-08-29 16:04:07
|
El 29 Aug 2006 a las 10:12, Bob Hanson escribi=F3: > probably something like > dots off > just turns them off > dots calculate > does the recalculation That looks great. And is similar to hbonds syntax!. > There may be complications with "geosurface" because "dots" and > "geosurface" operate via the same code, but no one is probably going to > use that option much anyway. We can deal with that later, I think. Agreed. "Open" surfaces may be an interesting choice for binding sites or contact sites (and are available with molecular isosurfaces, if I recall well). So just hiding unless recalculation is requested could be good for geosurfaces, same as you are proposing for dots. |