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:
- Create a “Plugin” super-class which will encompass Tools,
Extensions, and Engines – and also Colors and Gradients.
- Add a UI to change the Color plugin in the Engine (“Display Type”)
settings windows.
- 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:
- Create a “Plugin” super-class which will encompass Tools,
Extensions, and Engines – and also Colors and Gradients.
- Add a UI to change the Color plugin in the Engine (“Display Type”)
settings windows.
- 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