ChemWriter is a 2D chemical structure editor for the Web. Because it's written in Java and uses both the Swing and Java2D APIs, ChemWriter could be plugged into a variety of chemically-enabled user interfaces deployed within a browser, on the desktop, or in other contexts. The availability of this kind of developer tool would open the door to a large new area of interactive cheminformatics applications. This article, the first in a series, introduces Leafcutter, a new product designed to make this possible.

About the Software

Leafcutter is a framework consisting of reusable Swing components and supporting libraries for building chemically-enabled user interfaces. Based on ChemWriter, Leafcutter will contain most of the functionality of the 2D structure editor, but packaged as a set of highly customizable components. Whereas ChemWriter consists of configurable but finished applets for editing and rendering, Leafcutter will consist of components that can be used to build entirely new applets, desktop applications and other Rich Clients.

An alpha-stage developer preview is now available by request from Metamolecular. The package contains API documentation and source code for a sample Swing application (shown below).

The design constraints for tools used to build custom chemically-enabled user interfaces can vary significantly, but fine-grained control over appearance and behavior are top considerations. Depending on the specific use, controlling deployment footprint can also be critical. Leafcutter's design and implementation will address these needs uniquely.

What's New Here?

Although Leafcutter can be used to build traditional Cheminformatics applications, its main purpose will be to enable new kinds of applications that speak the language of 2D chemical structures natively.

Many of today's cheminformatics applications accept 2D chemical structures as input and render the same as output. But they're not generally designed to combine 2D chemical structures with their associated information in an interactive way.

For example, consider "Retro," a hypothetical application that enables Curt, a synthetic chemist, to plan his next synthetic route. Curt would draw his target molecule into a ChemWriter-like editor, as is typical for most reaction databases. But unlike other applications, Retro would interactively give Curt information about possible synthetic routes.

Clicking on a bond displays a side panel summarizing the number of published synthetic procedures that might be applicable. Clicking on the "Accept" button makes the bond disconnection and records the procedure hitset for later retrieval. Clicking on a "Suggest" button, highlights bonds representing viable disconnections, some of which might not have occurred to Curt otherwise.

Most synthetic organic chemistry databases are designed to be maps; Retro is designed to be a GPS device. A recent talk at the San Diego section of the ACS by Jun Xu offered some useful insight into the difference between these two approaches.

In addition, Curt communicates with Retro in his native language, the language of 2D chemical structures, by drawing, pointing and listening. It's the same way he communicates with his colleagues about chemistry.

The same concept could be applied to areas as diverse NMR and IR spectrum assignment and query, mass spectrometry, analyte detection, molecular mechanics calculations, and teaching reaction mechanisms.

Conclusions

If you plan to develop custom user interfaces that draw or manipulate 2D chemical structures, regardless of their design, Leafcutter will provide a powerful new tool for doing so.

Image Credit: Gavatron

Source: Hughes, Prieto-Davo, Jensen, and Fenical Org. Lett.

Duncan Hull offers an interesting commentary on the rapid increase in the number of biologically-oriented databases. He asks whether all of this abundance is leading to nothing more than a bad case of data indigestion, in which data is dumped into write-only "data tombs," never to be seen again.

A data tomb is created whenever the ability to generate data outstrips the ability to do useful things with it. Like the burial tombs of ancient civilizations, data tombs are created for many reasons and take many forms.

Where are chemistry's data tombs and what do they look like? Given that the number of free chemistry databases pales in comparison to the number free biological databases, the question may seem irrelevant.

Nevertheless, data tombs in chemistry are ubiquitous. The most obvious examples are the supplementary data sections of major chemical journals. These write-only databases suffer from dual afflictions of copyright restriction and electronic degradation.

The collective experimental sections of the world's chemical literature is, in effect, a vast catacomb of jealously-guarded, but poorly-catalogued treasures.

Data silos are an especially prevalent kind of data tomb that result when data is created for a single use and either for technical or political reasons never placed in a real database. SD files containing SAR data, PowerPoint slides containing tables of synthetic yields, and Word documents containing experimental procedures are some of the forms these chemical data silos take.

What chemical data tombs have you run into, and what methods did you use to raid them?

Image Credit: Duncan Hull

Source: Nikon Universcale

The last installment of this series showed how to set up an HTML testing harness for JSpecView. With the preliminaries taken care of, this installment will show how to enhance the user interface.

The Goal

The live applet shown above illustrates the changes that were made. As you move your mouse cursor into the spectrum area, you'll see a vertical red line appear and track the movements of the mouse. As you presss the mouse key to begin a selection, a grey rectangle will show you exactly where the selection area will be.

If you can't view the applet, be sure you system has JDK 1.5 or higher installed, and that you've enabled applets for your browser.

Clearly, these modifications need more work. For example, you can extend the selection box outside the boundary of the spectrum area. And green might be a better color for the cursor. Then again, maybe the cursor should use an alpha channel. But I digress.

One More Thing

Being a longtime Eclipse user, I prefer this tool for my Java development. So far, only the use of Ant has been described. Fortunately, Eclipse offers an elegant way to import an existing Ant project. File->New gives a dialog like the one shown below:

Selecting "Java Project from Existing Ant Buildfile" gives this dialog:

Filling in the fields as shown should give a fully-functional Eclipse project.

Still One More Thing

If you check the HTML source for this page, you'll notice that the applet tag is used to display the applet. Yet on Internet Explorer, there is no "click to activate" message. The reason is that Depth-First is using the excellent JavaScript library JActivating, which re-writes the applet tag so that it isn't detected by the Eolas workaround. This lets us stick with plain HTML, rather than using document.write to specify the applet.

Changing the Source Code

Too many changes were made to detail individually. In general, they related to:

• Removing non-applet classes such as those involved with the desktop application.

• Removing code flagged by Eclipse as unused.

• Editing the jspecview.common.JSVPanel source to add the UI modifications. The drawGraph, drawCursor, and drawZoomBox methods contained most of the changes.

The complete Eclipse project should be available from SourceForge shortly.

Conclusions

Given the right tools, modifying JSpecView is not that difficult. We've gone from raw souce code to a complete Eclipse project, and even added some functionality in the process.

Where would you like to take JSpecView?