SMILES again - Wikitech-l - lists.wikimedia.org

List overview All Threads
Download

SMILES again

New translations in LanguageEs.php...

MonoBook theme added to PhpWiki

Magnus Manske

15 Jun 2004 15 Jun '04

8:55 a.m.

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

Reply

Show replies by date

Neil Harris

15 Jun 15 Jun

9:22 a.m.

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

Reply

Neil Harris

9:51 a.m.

New subject: SMILES again -- another possible renderer

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 http://octet.sourceforge.net/ This does seem to understand more than just the SSMILES subset of SMILES, if my reading of the screenshot examples is right. -- Neil

Reply

Jens Frank

10:31 a.m.

New subject: SMILES again -- another possible renderer

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 http://octet.sourceforge.net/ 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

Reply

Fennec Foxen

11:36 a.m.

New subject: SMILES again -- another possible renderer

On Tue, 15 Jun 2004 12:31:35 +0200, Jens Frank <jeluf(a)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. :)

Reply

Neil Harris

16 Jun 16 Jun

2:30 p.m.

New subject: SMILES again -- another possible renderer

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 http://octet.sourceforge.net/ 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

Reply

Jim Higson

15 Jun 15 Jun

11:01 a.m.

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.

Reply

Neil Harris

16 Jun 16 Jun

2:42 p.m.

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

Reply

Jim Higson

4:09 p.m.

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(a)Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Reply

Magnus Manske

7:41 p.m.

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

Reply

Jim Higson

9:15 p.m.

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.

Reply

7299

days inactive

7300

days old

wikitech-l@lists.wikimedia.org

Manage subscription

10 comments

6 participants

tags (0)

participants (6)

Fennec Foxen
Jens Frank
Jim Higson
Magnus Manske
Neil Harris
Neil Harris