SF.net SVN: avogadro: trunk/libavogadro/src

On Jun 19, 2008, at 5:35 AM, benoitjacob@users.sourceforge.net wrote:

any reason why we might want to subclass Color? Or
is it not-performance-critical? Also there now are
many members to this class.

The Color class is definitely going to be subclassed. There are
already two main subclasses – the “default” and a residue-based
coloring.

What I’ve been meaning to do:

  1. Create a “Plugin” super-class which will encompass Tools,
    Extensions, and Engines – and also Colors and Gradients.
  2. Add a UI to change the Color plugin in the Engine (“Display Type”)
    settings windows.
  3. Add a “Custom Color” subclass.

I need to add similar support for the color gradients used in the
SurfaceEngine too.

Cheers,
-Geoff

On Thursday 19 June 2008 13:48:07 Geoffrey Hutchison wrote:

On Jun 19, 2008, at 5:35 AM, benoitjacob@users.sourceforge.net wrote:

any reason why we might want to subclass Color? Or
is it not-performance-critical? Also there now are
many members to this class.

The Color class is definitely going to be subclassed. There are
already two main subclasses – the “default” and a residue-based
coloring.

Ah OK, that’s what I didn’t know.

What I’ve been meaning to do:

  1. Create a “Plugin” super-class which will encompass Tools,
    Extensions, and Engines – and also Colors and Gradients.
  2. Add a UI to change the Color plugin in the Engine (“Display Type”)
    settings windows.
  3. Add a “Custom Color” subclass.

Sounds like a great plan, as long as Color objects are not too performance
critical. My only fear was with the surface engine as I feared it would do a
lot of Color operations to perform its gradient, but what you say below,

I need to add similar support for the color gradients used in the
SurfaceEngine too.

sounds very good.

Cheers,
Benoit