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

[Andrew Maclean]

Thankyou all for your comments and input.

Setting colors by name is needed in many classes scattered across several
modules, namely:
vtkLookupTable in module CommonCore
vtkPrpperty, vtkRenderer, vtkTextProperty in module RenderingCore
vtkPlot in module ChartsCore,
vtkPen in module RenderingContext2D,
using vtkNamedColor in module CommonCoreColor.
All these classes inherit from vtkObject so it is logical to create virtual
functions in vtkObject to facilitate the use of vtkNamedColors to set
colors by name.

I agree with David in that we need some kind of SetProperty in vtkObject to
get around module dependencies. It certainly looks like that in vtkPlot.h
the authors were leaning towards this idea in that:
virtual void SetProperty (const vtkStdString &property, const vtkVariant
&var);
virtual vtkVariant  GetProperty (const vtkStdString &property);
are defined.
One question here David is that in the signature you propose:
    virtual void SetProperty(
        const std::string& property, int component, const vtkVariant&);
I am not sure what the int component is meant to refer to.

Pat, I like your idea better than mine, I think the coding is simpler so I
will look at doing something along these lines. I was too focussed on
vtkNamedColors in my proposal. I would also like to see some sort of
dynamic property despatching, so any comments on how to implement this
would be appreciated.

One other question: Why not just use vtkVariantArray as I did in
SetProperty1 - it is simple to parse?

Thanks once again for all your comments.

Andrew




On Sat, Jun 15, 2013 at 2:21 AM, Pat Marion <pat.marion at kitware.com> wrote:

> The set color by name api in the example looks like:
>
>
> nc.SetColor(sphereActor.GetProperty(),"AmbientColor","Yellow")
> Perhaps an API like this instead:
>
> sphereActor.GetProperty().SetAmbientColor(nc.GetColor("Yellow"))
>
>
> I think that if the goal is to have dynamic properties in VTK's C++ api,
> it should be automated using the mechanism that is used for Python,
> client-server, Java, etc.  In the patch up for gerrit review, the dynamic
> property dispatch is manually implemented inside the SetProperty1() virtual
> function overload, which doesn't seem scalable.
>
>
> Pat
>
>
>
>
> On Fri, Jun 14, 2013 at 12:15 PM, David Thompson <
> david.thompson at kitware.com> wrote:
>
>> Hi John,
>>
>> > Modifying vtkObject just so that you can set colours in Lookuptables
>> strikes me as shockingly bad.
>>
>> I think that there is a general need for an abstract interface to set
>> properties; setting colors just happens to be driving the change. For
>> example, vtkPlot already has a similar method as do the statistics filters
>> (vtkStatisticsAlgorithm::SetParameter). We are just talking about moving
>> these down to vtkObject in order to allow the functionality elsewhere and
>> get around some module dependency issues.
>>
>> I am obviously in favor of adding something, although I would rather see
>> a single method with this signature:
>>
>>     virtual void SetProperty(
>>         const std::string& property, int component, const vtkVariant&);
>>
>> There is no reason vtkPlot cannot keep its alternate signature (as a
>> deprecated method).
>>
>>         David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>


-- 
___________________________________________
Andrew J. P. Maclean

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