From: Christoph S. <ste...@ic...> - 2001-07-21 15:33:06
|
Hi everybody, sorry for the long email below. You would do me a great favour if you donate a little of your valuable time to read and comment it anyway :-))) It discusses some important aspects of the future development of the CDK, JChemPaint (JCP) and JMol. 1. THE ACCELERATED RENDERER (JMOL/JCP RENDERERS IN GENERAL) Stephan wrote in to point out that his Renderer is far from complete, but I guess, that is understood by everybody. There is the question of how to interconnect Renderer, RendererModel and ChemModel in order to react dynamically to changes in the model chemistry. It is important to ensure the clear separation in the models. The RendererModel contains informations on how atoms and bonds are colored and how large they are drawn, etc., generally all the "artistic impression" settings. We might want to be able to draw scenes with several molecules, like a protein and its ligand. When doing so, we might want to draw the protein in a particular style and the ligand in another style. Or even parts of the macromolecule in different styles. This is not difficult at all if we allow a different RendererModel for each Molecule/AtomContainer in the ChemModel. From the things said so far it seems obvious that the Renderer should be as modular as possible, i.e. different renderer modules should be able to participate in the drawing of one scene. One, for example draw an AtomContainer as a ball and stick model and another one adds a translucent electron density surface around it, etc. So, how do we best implement this flexible behaviour? Which of the classes should have ideas of (i.e. references to) which other classes? The central renderer of course knows everything. It has a reference to the ChemModel (potentially containing multiple molecules) and a number of RendererModels which tell it (or its sub-modules) how to draw each of the molecules (-parts). How do we link a RendererModel and a Molecule/AtomContainer? Should each RendererModel have a reference to "its" Molecule (or AtomContainer, which can also be a fragment or just one atom or bond), for which it is responsible? Sounds ok to me. Now, another important aspect is listener notification. All the Models (Chem-, Renderer-) must have a listener administration mechanism. Please note that mechanisms for this are defined in the CDK, but these might need some refinement (like more expressive events, like Stephan has pointed out). Everything that is derived from ChemObject already implements ChemListener, so nothing to add here, just to improve :-) The Renderer should always react to the ChangeEvent from the models with rebuilding the scene in the most time- and resource-saving way. 2. THE GENERAL DESIGN OF JCHEMPAINT AND JMOL My favorite idea in this respect is that JChemPaint-CDK and JMol-CDK should actually be one application, with switchable look&feel (in a much broader sense than the Swing LnF). The ideal would be an architecture like the one that the JEdit people (http://jedit.sourceforge.net) have created. There is a central application which basically provides an infrastructure for components/plugins to be added to the application. The actual function is highly customizable, not only, but mainly by adding plugins. 2.1. They use BeanShell skripting for easy automation of tasks (http://www.beanshell.org/). 2.2 Another, perhaps the most important, feature is the EditBus. This message bus receives messages and forwards it to all registered components. Slava Pestov, the project coordinator of JEdit, writes: * The EditBus provides a way for plugins to communicate without knowing * too much about each other's internals. * * The EditBus is similar to the data bus inside a computer; there are * a number of components connected, and all components can send messages * to the bus. When a message is sent, all other components receive it, * and do something appropriate (or simply ignore it). I think a similar mechanism in the JChemPaint/JMol architecture would be very beneficial. After all, everthing that JCP/JMol components need to have in common is being able to draw what's in a ChemModel onto a canvas (and the controlers might want to be able to modify the model). 2.3. We should have a flexible menu design and actions defined by XML. Each plugin can easily add menu items. 2.4. The plugins can be docked to bottom, top, left, right, or can be floating. This is all highly configurable. Even the tool bars for controling either JChemPaint or JMol can be plugins. If more than one plugin is, say, docked to the left side, they will be ordered in layered panes. Since JEdit is GPL we can use much of their, I think, beautiful structure. Ok, I'll stop here. Have a nice saturday evening (or what ever part of the day still lies before you). Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Carl-Zeiss-Promenade 10, 07745 Jena, Germany Tel: +49(0)3641 643644 - Fax: +49(0)3641 643665 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |