I saw a nice command line utility which can generate GIFs from SMILES, a simple chemical markup language. Examples can be found here: http://www.daylight.com/dayhtml/tests/test-smi2gif.html
Can anyone find out * if this is PD/GPL * how to integrate it into wikipedia (SMILES->GIF->PNG???)
I would really like to have that one.
Magnus
Magnus Manske wrote:
I saw a nice command line utility which can generate GIFs from SMILES, a simple chemical markup language. Examples can be found here: http://www.daylight.com/dayhtml/tests/test-smi2gif.html
Can anyone find out
- if this is PD/GPL
- how to integrate it into wikipedia (SMILES->GIF->PNG???)
I would really like to have that one.
Magnus
No, smi2gif appears to be proprietary closed-source software. Quote: "The program is a combination of the Daylight SMILES, DEPICT, and DCGI toolkits and the CEX gif-formatting utility."
On the other hand, _this_ Java-based project: http://jmdraw.sourceforge.net/ _does_ appear to be what we want. Quote: "The JMDraw/SMILESViewer project was started by Christoph Steinbeck http://www.ice.mpg.de/%7Estein from the ChemoInformatics group http://www.ice.mpg.de/departments/ChemInf/ at the Max-Planck-Institute of Chemical Ecology http://www.ice.mpg.de in Jena. It is an Open Source project, the sources are published under GNU Lesser General Public License, LGPL http://www.gnu.org/copyleft/lesser.html. " Next question -- can it be run on an entirely open-source infrastructure?
-- Neil
Neil Harris wrote:
Magnus Manske wrote:
I saw a nice command line utility which can generate GIFs from SMILES, a simple chemical markup language. Examples can be found here: http://www.daylight.com/dayhtml/tests/test-smi2gif.html
Can anyone find out
- if this is PD/GPL
- how to integrate it into wikipedia (SMILES->GIF->PNG???)
I would really like to have that one.
Magnus
No, smi2gif appears to be proprietary closed-source software. Quote: "The program is a combination of the Daylight SMILES, DEPICT, and DCGI toolkits and the CEX gif-formatting utility."
On the other hand, _this_ Java-based project: http://jmdraw.sourceforge.net/ _does_ appear to be what we want. Quote: "The JMDraw/SMILESViewer project was started by Christoph Steinbeck http://www.ice.mpg.de/%7Estein from the ChemoInformatics group http://www.ice.mpg.de/departments/ChemInf/ at the Max-Planck-Institute of Chemical Ecology http://www.ice.mpg.de in Jena. It is an Open Source project, the sources are published under GNU Lesser General Public License, LGPL http://www.gnu.org/copyleft/lesser.html. " Next question -- can it be run on an entirely open-source infrastructure?
-- Neil
You can test it online at http://jmdraw.sourceforge.net/SMILESViewerDemo.html Also, the parser for the open source project is the SSMILES subset language only.
A bit more Googling has now turned up:
http://structure.sourceforge.net/screenshots.html
(Java again) which is based on
This does seem to understand more than just the SSMILES subset of SMILES, if my reading of the screenshot examples is right.
-- Neil
On Tue, Jun 15, 2004 at 10:51:41AM +0100, Neil Harris wrote:
Neil Harris wrote:
Magnus Manske wrote:
I saw a nice command line utility which can generate GIFs from SMILES, a simple chemical markup language. Examples can be found here: http://www.daylight.com/dayhtml/tests/test-smi2gif.html
Can anyone find out
- if this is PD/GPL
- how to integrate it into wikipedia (SMILES->GIF->PNG???)
I would really like to have that one.
Magnus
No, smi2gif appears to be proprietary closed-source software. Quote: "The program is a combination of the Daylight SMILES, DEPICT, and DCGI toolkits and the CEX gif-formatting utility."
On the other hand, _this_ Java-based project: http://jmdraw.sourceforge.net/ _does_ appear to be what we want. Quote: "The JMDraw/SMILESViewer project was started by Christoph Steinbeck http://www.ice.mpg.de/%7Estein from the ChemoInformatics group http://www.ice.mpg.de/departments/ChemInf/ at the Max-Planck-Institute of Chemical Ecology http://www.ice.mpg.de in Jena. It is an Open Source project, the sources are published under GNU Lesser General Public License, LGPL http://www.gnu.org/copyleft/lesser.html. " Next question -- can it be run on an entirely open-source infrastructure?
-- Neil
You can test it online at http://jmdraw.sourceforge.net/SMILESViewerDemo.html Also, the parser for the open source project is the SSMILES subset language only.
A bit more Googling has now turned up:
http://structure.sourceforge.net/screenshots.html
(Java again) which is based on
This does seem to understand more than just the SSMILES subset of SMILES, if my reading of the screenshot examples is right.
Personaly, I'd like to avoid using client side Java.
From my impression, Octet only provides an ASCII output renderer?
jmdraw uses the java.awt Canvas class to draw, which looks like a client only component to me, but I'm not that familiar with Java.
Regards,
JeLuF
On Tue, 15 Jun 2004 12:31:35 +0200, Jens Frank jeluf@gmx.de wrote:
Personaly, I'd like to avoid using client side Java. jmdraw uses the java.awt Canvas class to draw, which looks like a client only component to me, but I'm not that familiar with Java.
You don't need to display a java.awt.Canvas to draw upon it; it should be available server-side without any problems. As I recall, PieSpy (http://www.jibble.org/piespy/) also uses similar techniques to output pretty graphs.
But if you tweak the thing around a little, I hope you can have it making PNGs instead of GIFs, of course. :)
Jens Frank wrote:
On Tue, Jun 15, 2004 at 10:51:41AM +0100, Neil Harris wrote:
Neil Harris wrote:
On the other hand, _this_ Java-based project: http://jmdraw.sourceforge.net/ _does_ appear to be what we want. Quote: "The JMDraw/SMILESViewer project was started by Christoph Steinbeck http://www.ice.mpg.de/%7Estein from the ChemoInformatics group http://www.ice.mpg.de/departments/ChemInf/ at the Max-Planck-Institute of Chemical Ecology http://www.ice.mpg.de in Jena. It is an Open Source project, the sources are published under GNU Lesser General Public License, LGPL http://www.gnu.org/copyleft/lesser.html. " Next question -- can it be run on an entirely open-source infrastructure?
-- Neil
You can test it online at http://jmdraw.sourceforge.net/SMILESViewerDemo.html Also, the parser for the open source project is the SSMILES subset language only.
A bit more Googling has now turned up:
http://structure.sourceforge.net/screenshots.html
(Java again) which is based on
This does seem to understand more than just the SSMILES subset of SMILES, if my reading of the screenshot examples is right.
Personaly, I'd like to avoid using client side Java.
From my impression, Octet only provides an ASCII output renderer?
jmdraw uses the java.awt Canvas class to draw, which looks like a client only component to me, but I'm not that familiar with Java.
Regards,
JeLuF
I agree with you completely about not using client-side Java: client plugins of any sort are a bad idea, in my opinion. As Fennec pointed out, we should be able to render the rasters server-side, and then treat it exactly like TeX: we should be able to re-use nearly all the TeX-integration infrastructure, just replacing the TeX -> .png black box with a SMILES -> .png black box.
-- Neil
Is there a policy on client-side code (such as applets) on the wiki when doing something that can't be done on the server.
For example, visit any of the links from here http://jmol.sourceforge.net/preview/
I find this kind of thing simply stunning, and the kind of thing an electronic encyclopedia should use to take advantage of over paper ones.
IMO a 3D, rotatable view of a molecule gives far greater and easier understanding of the structure, especially to a newcomer.
Jim Higson wrote:
Is there a policy on client-side code (such as applets) on the wiki when doing something that can't be done on the server.
For example, visit any of the links from here http://jmol.sourceforge.net/preview/
I find this kind of thing simply stunning, and the kind of thing an electronic encyclopedia should use to take advantage of over paper ones.
IMO a 3D, rotatable view of a molecule gives far greater and easier understanding of the structure, especially to a newcomer.
I think plug-ins are bad; they limit software choices, which should be left to the client. However, in addition to generating a nice simple 2D picture, the SMILES-processor mentioned above should be able to output any of a number of different chemical-markup representations, which could then be made available via a link, so that your favourite chemical-computing software can be launched (in the same way that you might launch a viewer for any other external content). Then you can do _far_ more than just spin it: you can calculate energies, visualise orbitals....
Are there any chemists here with an opinion on this?
-- Neil
I think plug-ins are bad; they limit software choices, which should be left to the client.
In general I agree, but I think if sensibly aproached they can enhance the wiki. For example those without a JRE installed could be sent a prerendered png, and those with could be sent the applet.
IMO plugins aimed at a specific purpose are bad - ie the user having to install software *just* to view molecules, but well supported, general purpose plugins like java and flash are accpetable provided those who don't have them aren't given 'broken' pages.
However, in addition to generating a nice simple 2D picture, the SMILES-processor mentioned above should be able to output any of a number of different chemical-markup representations, which could then be made available via a link, so that your favourite chemical-computing software can be launched (in the same way that you might launch a viewer for any other external content). Then you can do _far_ more than just spin it: you can calculate energies, visualise orbitals....
Are there any chemists here with an opinion on this?
-- Neil
Wikitech-l mailing list Wikitech-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
Jim Higson wrote:
I think plug-ins are bad; they limit software choices, which should be left to the client.
In general I agree, but I think if sensibly aproached they can enhance the wiki. For example those without a JRE installed could be sent a prerendered png, and those with could be sent the applet.
IMO plugins aimed at a specific purpose are bad - ie the user having to install software *just* to view molecules, but well supported, general purpose plugins like java and flash are accpetable provided those who don't have them aren't given 'broken' pages.
I for one don't like plugins, but agree that they *can* be of *additional* use. So, why not display the molecule as a PNG, then open a new browser window with a 3D/whatever applet when the user clicks on it? alt="Click here to see it in 3D (EvilJava required)." would give a hint.
Magnus
I for one don't like plugins, but agree that they *can* be of *additional* use. So, why not display the molecule as a PNG, then open a new browser window with a 3D/whatever applet when the user clicks on it? alt="Click here to see it in 3D (EvilJava required)." would give a hint.
That might be the best compromise.
My opinion on applets for the wiki is they're fine so long as they run in the GNU RTE and the 'non-rich' content is still provided.
Going OT from SMILES, but for articles on, for example, AVL trees there are quite a few good, free applets that let the user add/remove nodes from an animated diagram. Being able to see the nodes move is a good visual aid, and makes it a lot easier to get a feel of the overall thing than a text + static image description.
wikitech-l@lists.wikimedia.org