Re: [Jmol-developers] what creates the image?

[Miguel <mi...@jm...>]

Sascha wrote:

> I'm working on the C=23 port, and I'm through org.jmol.g3d

This is a standalone package.

You should be able to write some standalone test programs that use
org.jmol.g3d to verify that it is working properly.


> and
> javax.vecmath, which seemed like a foundation level to start with.

This should be very straightforward. No ui. If there is a 'conversion
tool' then it should just work.


> Now I
> want to make Jmol paint into an image which I can copy to the screen.

Per my message above ... I recommend a small test program that uses and
verifies org.jmol.g3d

> I'm having trouble understanding where each of these classes fit into
> the structure of a viewer, and which of them I should use as the contac=
t
> point for integrating with my C=23 app. Can anyone give me a brief
> description of each of these classes?
> org.jmol.api.JmolViewer,

This is only an API specification.

Its purpose is to:
 1. put the external API in one place
 2. make it easier to write the doc
 3. make it easier to identify all the methods that should *not* be publi=
c

> org.jmol.viewer.Viewer

The core of the implementation.

> org.jmol.viewer.FrameRenderer

The thing that does the drawing.
It walks over the data structures and calls individual Renderers.
The word 'frame' is completely incorrect and should be changed.

Since the title was 'what creates the image', then I suppose that the
answer would be the FrameRenderer.

> The library relies on a lot of collaboration between clasess; that will=

> probably make it easier to swap in different implementations, but it
> makes it hard to grok the all-over structure. Any help would be
> appreciated.

All of that stuff got pushed together into one package quite recently. I
had to put it into one package because internal methods were 'public' ...=

and people started to use them.

> ...and then how do the adapters fit in? Is this just about sharing
> *data*, not images?
> org.jmol.api.JmolAdapter

The adapter is the file IO mechanism. We are adapting an external data
representation to the internal Jmol representation.

The primary implementation of this is org.jmol.adapter.smarter

The name is 'smarter' because it is more intelligent than the first
'simple' adapter.

Other adapters (such as the cdk adapter) allow Jmol to import data from
other data models.


Miguel