> it always contains "atoms selected!" in JMol, maybe a select command > could return an array instead of a string? Rather than 'instead', perhaps we should add an additional parameter. That way we will maintain compatibility with existing web applications.
> so if I select Glu134:B, > for example, I would get an array with: > > number of atoms selected > id of group selected > number of selected group > chain of selected group > > what other info is accessible? Lots of things :-) > could JMol tell me that I selected an > atom in the ligand, for example? or the color? Yes. Uhh ... in 25 words or less ... what is a ligand? > I guess I'd like to have all of the Atom properties accessible - but I > bet that is a chore ;-) maybe some middle ground though... Actually, that is exactly the right way to think about this problem. All properties of an atom should be accessible from the atom object. What do you think about something like this: A selection set should allow you to enumerate all the atoms in the set. (Or perhaps there is an iterator which always enumerates the atoms in the currently selected set) Given each of these atoms you can inquire about its properties. Does that sound right? > for example, click on atomno=1738 in 1d66.pdb and Chime will return: > > Atom: O 1738 Hetero: HOH 343 Chain: B > > > parsing this kind of string in javascript is a bit of a pain; again, > as a developer, it would be much better to have this as a well-formed > array instead. (see my comments above about select.) and it would be > even better if the atom data included some state info - what color is > it, how is it rendered... I think that the PickCallBack should pass you at atom object (or atom ID). Using this, you should be able to get the properties of the atom. What does PickCallBack do if you rubber-band select a rectangle of atoms in Chime? ( Or is this functionality not available? ) > I do wonder if JMol might be do a better job than either Chime or > RasMol at returning well-formed data about the loaded structure. for > example, all of this should be accessible info: > > the url > the compound > the organism > if a crystal, the resolution > the number of chains > identity and chemical formula of any hetero groups > the ligand > the helices or sheets > the primary sequence > the current 3D position These should be properties of the current 'model' and should all be accessible. > one can write a javascript method for finding most of this, using > 'show pdbheader' in Chime, but what a pain. maybe JMol can have a > suite of 'show info' commands to access structure data like this? Writing code to parse the text output would be a disaster. > sorry for piling on, but I'm salivating at the prospect of having all > of this data, well-formed and ready to use. Actually, this kind of 'piling on' is *exactly* the kind of feedback we are looking for! Miguel (The text below is not intended to be a 'lecture' for anyone in particular ... I just wanted to write it down someplace) Here is another one of our *challenges*. The RasMol 'scripting language' isn't a real 'language' in the programming sense of the term. Down the road we will have the chance to define/build one or more 'Jmol scripting langages' that are better suited for web application development ... in JavaScript and/or PHP and/or Python and/or something. But that is for the future. But for now we need to focus on what extensions we should provide to the RasMol/Chime scripting language that fit within the existing development methodology of the existing installed-base of users. ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Jmol-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-users
