On Saturday 9 April 2005 18:05, Peter Murray-Rust wrote: > At 10:56 09/04/2005, Egon Willighagen wrote: > >On Saturday 9 April 2005 10:55, Peter Murray-Rust wrote: > > > [crossposted to 3 lists + Openbabel; reply thoughtfully] > > > > > > At 20:54 08/04/2005, Egon Willighagen wrote: > > > >A first try was already in CVS for quite some time, but I finally got > > > > around it to complete it. It's a JChemPaint plugin, well... viewer > > > > only, for Jmol :) Screenshot attached. Available from CVS [1] and > > > > soon on the CDK plugins website (when I got things automated again). > > > > > > Egon, this is very beautiful - well done. > > > > > > it raises an important point which is something I think the BlueObelisk > > > should take on board - the bond orders are missing. > > > >Depends on what file you opened. If the Jmol view has bond orders, then > > the JCP plugin should show those too.... possibly pending aromatic bonds > > in Jmol which do not seem to be transferred to the plugin correctly... > > I think it's more problematic. It is OK for Jmol to show single bonds by > default
By default it shows what's in the file... this file apparently did not contain bond orders... it was the XYZ format... Sofar the plugin does this: replace explicit hydrogens by implicit hydrogens. This should be made optional. And I want to add this options too: - perceive bond orders > since that has been the graphics convention for 30 years (although > not for physical models). And you often have a clue from torsions and bond > angles. However if you display benzene rings *in 2D diagrams" with single > bonds (as in the picture) then it's wrong. Chemists are so used to looking > at 2D diagrams with bonds and orders rather than hydrogens and will > seriously misinterpret pictures with the wrong orders. Put simply, they > would regard any program that didn't get the bond orders right as not worth > using. Ack. > In a similar way it is still possible to display 2D diagrams as 3D objects > in Jmol. This is also wrong. I know its difficult, because the files often > don't indicate the type of the coordinate but we have to do everything > possible to prevent it. Chemists (and even more biologists) will not > realise its a form problem, they will simply either believe the result or > decide Jmol is wrong. ... getting chemists aware of file content problems anyway is a problem. > >Did we decide yet on SF versus some other server? The QSAR.sf.net project > >basically serves the same purpose as BO, but then for (open source) QSAR > >specifically, and using SF as a service provider is working well so far... > >with QSAR we don't really have sourcecode, but we do use CVS for > >documentation (website and dictionaries) and this works well... > > If people want to use it in this way, fine. We don't need to proliferate > sites. There are philosophical differences between Open Source and Open > Data but I doubt they matter to the current community. Not sure what you mean here... Egon -- [EMAIL PROTECTED] PhD student on Molecular Representation in Chemometrics Radboud University Nijmegen http://www.cac.science.ru.nl/people/egonw/ GPG: 1024D/D6336BA6 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jmol-developers mailing list Jmol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-developers
