[vtk-developers] Setting color properties directly by name in VTK.

[Biddiscombe, John A.]

>
There has been a request to have the ability to directly set colors using color
 names in vtkLookupTable and other classes. I must admit that after working on
 converting lots of TCL to Python tests, I felt the need for it too!
<

Modifying vtkObject just so that you can set colours in Lookuptables strikes me as shockingly bad.

I vote no on principal.

JB

From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Andrew Maclean
Sent: 14 June 2013 11:05
To: VTK Developers
Subject: [vtk-developers] Setting color properties directly by name in VTK.

Apologies for the long e-mail but this particular code change submitted for
 review does entail a change to vtkObject.h. Hence the need for all you
 developers to be comfortable with such a change. Alternatively you may be
 able to suggest a better method of achieving this.

There has been a request to have the ability to directly set colors using color
 names in vtkLookupTable and other classes. I must admit that after working on
 converting lots of TCL to Python tests, I felt the need for it too!

The current ways of setting colors by names are exemplified by:
TestNamedColorsIntegration.cxx
TestNamedColorsIntegration.py
These work but are not very elegant.

In order to overcome these limitations and make setting of colors more
 intuitive for users, I have put the following up for review:

 http://review.source.kitware.com/11412

Once again thanks to David Thompson for suggesting this approach.

This approach does require a change to vtkObject.h, by introducing a function:
 virtual void SetProperty1(vtkVariantArray*)
The upside of this is that, because it has a variant array as a parameter, there
 will be other uses for this function in the future, most probably setting
 parameters in a similar fashion to what has been done here.

The rationale for this implementation is as follows:

VTK uses a single inheritance model and is modularized so the logical thing is
 to introduce a virtual SetProperty1 function, implement it in the
 appropriate classes e.g. vtkLookUpTable and call this from vtkNamedColors.

This would mean that in our code we can do things like:
nc.SetColor(lut,"TableValue",1,"DarkGreen");
which under the hood implements:
lut->SetTableValue(1,0,1,0,1);

You can see implementations in:
TestSetColorsByName.cxx
TestSetColorsByName.py.

So, in summary, we have an approach for setting colors by name by doing the
 following:
1) Implement the classes including vtkNamedColors,
2) Call SetColor in vtkNamedColors passing the address of the object you want
   to set the color in, the name of the property and the color to set.

Other approaches tried:

A) Not changing the VTK API. The only way is to implement interface classes
   that, when constructed, take an instance of vtkNamedColors and
   e.g vtkLookupTable. Then you implement a function to set by color name.
   This approach generates a bit of extra coding by by the programmer and is
   a really kludgey (in my opinion). You also have to implement this for the
   other classes that have set color functions. Also, whenever you write a new
   application, you have to do the same thing all over again.

B) Introducing pointers to the classes that set colors in vtkNamedColors:
   This will not work for two reasons:
     1) The modular nature of VTK introduces cyclic dependencies - to resolve
        this would require a lot of code reorganization and reduce the
        modularity of VTK. Not a good thing!
     2) vtkRenderer is a factory and concrete implementations happen
        after instantiation.

C) (Not tried) It may be possible to add helper classes and have the color
   owning classes create them. A virtual class would have to be added to
   vtkCommonCore. This approach does not allow you to use your own instance
   of vtkNamedcolors as classes of interest e.g. vtkLookupTable need to
   define SetColor methods that will need to define an instance of the helper
   and then obtain a color with it.

Regards
   Andrew


--
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130614/1a7e4b33/attachment.html>