Re: [Cdk-jchempaint] On Modules and Models

[Arvid <gog...@us...>]

You are right there is some missing code, I have included it bellow.
The 'modules' are like the SymbolTreeFactory in your branch as they are used
to build the RenderingModel and their structure should probably change.

The basic function of the modules is for reuse. While looping over the atoms
and bonds in the atomcontainer and generating rendering elements you may
want to pass the atom/bond to a highlight module and to the basic drawing
module, here moduls work ok. If you want to add isotop information it might
be better to extend the symbol drawing module with extra functionality.

This raises the question on how to turn on and off thees different rendering
options in a more advanced application, you might have checkboxes for
different options that can be checked/unchecked. This be no problem with the
model described above. I will rework the modules so they more closly match
what is described abov and take in to account the order as described in your
second post.

I agree we should design for the funcunality we need right now and not what
might be needed in the future.

    private RenderingModel generateRenderingModel( RenderingModel model ) {

        AbstractModule superModule = new AbstractModule() {

            @Override
            public IRenderingElement accept( IAtomContainer ac, IAtom atom,
                                             IRenderingElement element ) {

                return element;
            }

            @Override
            public IRenderingElement accept( IAtomContainer ac, IBond bond,
                                             IRenderingElement element ) {

                return element;
            }

            @Override
            public Renderer2DModel getModel() {

                return r2DModel;
            }
        };

        IRenderingModule modules =
                new AtomSymbolModule(
                    new BondModule(
                    new AtomModule(
                    superModule ) ) );
        if ( atomContainer == null )
            return model;

        for ( IBond bond : atomContainer.bonds() ) {
            model.add( modules.accept( atomContainer, bond, null ) );
        }
        for ( IAtom atom : atomContainer.atoms() ) {
            model.add( modules.accept( atomContainer, atom, null ) );

        }
}

Hi,
>
> I've looked at Arvid's code, and Egon's code. And, well. Well.
>
> Note : I get passionate about getting the design right, and I hope I
> don't come across as aggressive - I am fully prepared to change my
> mind...
>
> First, about Egon's latest mail:
>
> >> 1. a really tiny small molecule viewing applet [SNIP] with simple
> functionality for
> >> highlighting, [SNIP] just view only
> Generate images server side, with the right atoms highlighted. Like:
>
>
> http://compbio.dcs.gla.ac.uk/tops/view/cath/100x100/3.5.6.7.8.9.10.11.12.13/1lr5A0.gif
>
> (btw, it used to be that you could change 100x100 to say 500x500 and
> the image would be larger, but then it got broken by the idiot
> 'maintaining' it).
>
> >> 2. a somewhat larger editing applet, with a bit more functionality.
> Right.
>
> >>Possibly, this one would support indexing, but I'd rather not.
> I don't know what you mean by indexing, but if you mean the KDTree
> stuff I did - don't worry about it. It was a nice theoretical idea,
> but makes so little difference for real world examples that it would
> only ever have a niche uses (graphene, large 2D crystal displays,
> large sets or molecules) which there may not even be any need.
>
> >>Importantly, this one would need some functionality on interpretation
> >> of mouse gestures
> Fine, whatever, I don't care about how the rendering code is
> interacted with. You can use a trackball and a head-dobber if you
> like.
>
> >>3. a full fledged application with all the bells and glamours. In SWT.
> I like the idea of an app with glamours. Could it also have
> enchantments, conjurations, abjurations, divinations, and summonings?
> :)
>
> >> 4. a renderer that can display reaction mechanisms with full electron
> movements etc
> Definitely. That can be handled by having "annotations" to a diagram,
> that are not reflections of the ChemModel, but similar in principle to
> text labels.
>
> Fine, so none of this convinces me of the need for modules. Oh wait,
> there's more:
>
> >> - we need to pick rendering functionality in great detail (but not too
> much)
> No we don't.
>
> >>- we need to pick controller functionality
> Don't care. Nothing to do with the renderer.
>
> >>- custom renderers are combined by aggregating individual
> renderers,instead of extending on each other
> This is a sound principle, I'm told (and I believe them :) But
> unwanted flexibility. I _think_ you mean something like this:
>
> IRenderer renderer = new AtomRenderer(new BondRenderer());
>
> as opposed to :
>
> IRenderer renderer = new BondRenderer(new AtomRenderer());
>
> so that you could control things like rendering the bonds before the
> atoms and v.v. - now, here's the key...
>
> We never want to do one of these.
>
> Bonds are ALWAYS renderered first, with atoms ALWAYS rendered second.
> Otherwise, the atom won't cut the bond ends properly. Even if you did
> the (tricky, expensive) calculations to cut the bonds to the
> intersection of the atom bounding box, you would be left with two
> different ways to do the same thing, for no gain.
>
> I may have made the wrong assumption here, grasped the wrong end of
> the stick, and so on, so please tell me I am wrong (and a fool, and so
> on :)
>
> Another thing is that I can't work out how to get Arvid's
> RenderingModules to work. I ended up with code like:
>
>    new AtomModule(new AbstractModule() {} );
>
> which must be my mistake. I don't get why the Abstract base class
> holds a reference to an instance of its own type, which the derived
> classes then can default to. It looks like the code will call its
> methods recursively, with no base case - causing call stack overflow.
> Am I wrong?
>
> >>- each renderer comes with it's own IRenderingParameter (a rename like to
> apply anyway, as using
> >>RendererModel is confusing as it might refer the the model being
> rendered...)
> I agree that a name change from RendererModel is in order. I assume
> you mean the Renderer2DModel, and not Arvid's RenderingModel...
> The Renderer2DModel is stuffed full of rubbish, frankly. It should not
> hold the coordinates, and many other things. I suggest splitting it
> into Parameters for generating the RenderingModel (which I would
> prefer just to call a "Diagram") and the Parameters for drawing the
> Diagram. We can talk about that later, it's not so important right
> now.
>
> Right, this is turning into a thesis, so I will post another mail
> about Visitors patterns in a while.
>
> gilleain
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Cdk-jchempaint mailing list
> Cdk...@li...
> https://lists.sourceforge.net/lists/listinfo/cdk-jchempaint
>