Re: [Cdk-devel] RFC #12 common API for CDK renderers

[Edgar L. <ed...@up...>]

Hi,

>A API to be implemented by all CDK renderers and possible others, e.g.
>Jmol's 3D renderer. The API would define how the renderer can be instantiated
>and how a molecule can be passed to the viewer that should be displayes by
>the viewer.
>
Good plan ;-)

>At this moment CDK includes two working renderers (and one that does not
>work, which is Renderer3D): AcceleratedRenderer3D and Renderer2D. Both should 
>use the same API proposed in this RFC. 
>
>The 3D renderer uses this API at this moment:
>
>AcceleratedRenderer3D()
>AcceleratedRenderer3D(AcceleratedRenderer3DModel)
>void createSceneGraph(TransformGroup)
>void setBackGroundColor(Color)
>
Actually I already use a different API and that is the reason why it 
takes so long to bring the changes into a form I could submit into the 
cvs, basically the renderer interface shrinked to:

AcceleratedRenderer3D()
addContent(BranchGroup)
removeContent()
createSceneGrapgh()

Thus making the renderer more stuping and moving a lot of logic into the model which now inherits from a general ChemLookAndFeel class. The ChemLookAndFeel stores all the visual information like size of balls or sticks in ball and stick representation, the colors and so forth.
The ...Model class additionally contains then methods:
 add(ChemFile)
 setRenderer(AcceleratedRenderer3D)

<snip>

>I propose it is the Panel/Canvas that needs the common API to achieve the
>ability to switch between renderers in GUI applications. The API I think of 
>looks like:
>
>1. The class must subclass the java.awt.Component, or one of its
>   subclasses, like Canvas3D and JPanel
>2. The class must have a constructor that takes zero parameters.
>    This constructor should set a default RendererModel.
>2. The class must implement the to be written CDKRenderer Interface
>    which looks like:
>
>public interface CDKRenderer {
>
>    public void setChemObject(ChemObject) throws CDKException;
>
>}
>
>this method will change the molecule and paint the new molecule.
>Note that I deliberately took ChemObject instead of Molecule or
>AtomContainer. The Renderer must be able to actually display
>other things than just AtomContainer's... think of Reaction's and
>animation's e.g. stored as ChemSequence's.
>
>Also note that their is no defined interface for setting the RendererModel.
>At this stage I am unsure wether that would further easy the switching
>process.
>
Hmm, I think I still need to think a lot of this more and maybe I start drawing some UML stuff, so that we have something to argue on.
Actually I think we need a special class for storing all the visual parameters, we need a good Model class that represents the whole chemical universe we look at on the screen and several renderer that know how to show this information. This means I think we need to define an Interface for the CDKModel (sticking to your name idea) too.

Will try to think into this more over the weekend

Edgar

p.s.: We still agree on using ArgoUML - right?


--
Edgar Luttmann

University of Paderborn, Germany
Department of organic chemistry
                                        		office: J6.302
Warburger Str. 100                      	phone:  (+49) 5251 60-2498
33098 Paderborn                         	eMail:  ed...@up...