Some Stuff

More pictures, mainly for my own benefit. First, a possible refactoring of some bioclipse modules: Where boxes are modules, and lines indicate dependencies. There's a lot of work in that arrow! Only the compute plugin and the seneca plugin have been ported (however incompletely) so far. The second image shows the extension points for the putative CASE plugin. One is the judge extension point that already exists in the seneca plugin, and the other is a structure source: This is more general than just a structure generator extension point, and could also include sources from files or databases. I think that this makes sense...

Sorry, but some more opaque UML diagram from the cdk.controller package. First, the Controller2DModules: Which is very simple, although the names are a bit clumsy. I would favour using a sub-package called "module" and then having "AddAtomModule", "ChangeFormalChargeModule", and so on. Doesn't really matter, as they will likely not be used very often. The other image is more complex; it shows the class that implements IChemModelRelay and how it interacts with the two current Swing event handlers. The circles represent interfaces. The MouseListener and MouseMotionListener are, of course, the interfaces from the java.awt package that are normally used by java programs. Now to figure out how to actually use all this!

One way to understand a piece of software architecture is to make a diagram out of it: Also, it's an excuse to make another diagram... Oh, and here's the version with packages:

I knocked up a small program to analyse the various options that the Renderer2DModel supports. It uses reflection to get the set methods and create controls, then calls the appropriate get method when the control changes. Another aspect of the Java2DRenderer it shows is that many of the options do nothing as they are not wired in. Finally, it is clear that there are certain options that probably shouldn't be there, such as the selection box, or are quite mysterious, such as the ClipboardContent...

Thorsten's patch here: https://sourceforge.net/tracker/index.php?func=detail&aid=2128802&group_id=20024&atid=320024 makes things much better. I don't yet know exactly why, but better: (ignore the "in" and "out", they were an experiment and not relevant.

So: it sortof works... The missing piece of the puzzle was this line: GeometryTools.scaleMolecule(molecule, getPreferredSize(), 0.9); where getPreferredSize() is just a container call, and the 0.9 is a scale factor. This is too magical for my tastes. You apparently don't have to scale benzene, but you do have to scale pyridine!

Okay, so this code (only valid pastebin for a month...) produces some odd results. For c1ccncc1: whereas for c1ccccc1: So, something may be wrong with the text scaling. In fact, the code looks like it is applying a transform to the graphics object, then scaling the font...

Soooo. I have been messing around with what I've optimistically been thinking of as an 'alternative' JChemPaint renderer rather than just a botched refactoring. I started with the code by Niels Out ( blog ) and messed around with it a bit. Here is a diagram of part of where it is at: This is meant to be valid UML, but the message is the same : "Overly. Complex." The basic idea is that the parent SymbolTreeFactory handles the logic of what bonds to create, and the child factory creates a tree suitable for AWT. There's a name problem here, as "AWT" is not right for Java2D; also I'm not sure why I decided on "SymbolTree" as it's not really a tree as such. It could be, using a Composition pattern perhaps, but that seems unnecessary. Anyway, the point  of this is to make separate AWT and SWT renderers, while sharing as much code as possible. This may not be the way to do it, but it is a  way to do it.

Hmmm. Seems there are dragons lurking in the PubChem data: (oxygens not shown). It has an 801 character smiles string! It's called "Inulin" apparently, and it's a polysaccharide: PubChem record

With a slight change of data, and a change to the bond order settings, now 2,737 out of 5,739 match exactly. 1,114 of the rest get the right one in the top 10. That still leaves almost 2,000 - but some of these are clearly poor experimental data.

I made a tiny minimal tool for me too look at the results of spectra matching. Re-inveting several wheels, no doubt, but it does use CDK trunk rendering...sortof.

Heh: I should point out that a lot of the nested packages are "data" packages with no java code in. There are a number of empty packages in the source tree, which are not included.

And other TLAs (three-letter acronyms)... So, in trying to find out what the status of the JChemPaint code, there seems to be a lot of stuff, but not all of it works. So, in order to understand the plan, and as a suggested architecture, have this diagram: It's not proper UML, but the package symbols are right. What this sketch suggests is that if there is graphics-independant code in the cdk.renderer package, then this package would take a molecule (or a reaction set, or a chemobject, etc) and 'render' it into graphical objects. These would then be passed (the "renderer objects" oval) to the package (n.b.cdk.jchempaint or o.o.jchempaint) that is actually using a Graphics or GC object to draw with. Otherwise, the renderer package is really doing nothing useful.