[vtk-developers] new vtkTextActor class and slight mapperchanges

[Sebastien BARRE]

At 6/12/2002 12:00 PM, John Biddiscombe wrote:

>I don't believe this is going to be a problem. The TextMapper API is not
>subject to much change.

I'm working on the text mappers in fact. I'll add a couple of members.

> > In the long run, this might introduce a risk that they run out of sync.
> > Painful.
>
>I disagree. These classes are not complex and in my view the TextMapper
>class is incorrectly designed. a "Mapper" should be responsible for
>converting primitives into screen objects, the presence of all the options
>in TextMapper is in my opinion a mistake. The Bold/Italic. Justification
>options should be in the actor (or at least a "text" property) and the
>Mapper should just do the donkey work of creating the relevant opengl calls
>etc.

I agree 200% that there should be a text property like there is a vtkProperty.

But I don't think this is a reason to duplicate an API just for 
"convenience". I mean, who's convenience is it now ? If I follow you in 
terms of "complexity", this should look even worse since the vtkTextActor 
"blurs" several API together by grouping them altogether, don't you think 
so ?

Once again, vtkTextActor is a good "convenient class", so I ask for a 
compromise here which is:

   - you will still be able to create a unique object, i.e. vtkTextActor, 
instead of a vtkTextMapper and a vtkActor2D.

   - instead of doing actor->SetBold(), you just have to do as usual:
     vtkTextMapper* mapper = actor->GetMapper();
     mapper->SetBold();

  - maintenance is easier (one API), and you don't blur both APIs in a 
single blob. I mean, vtkTextMapper will for sure stay in VTK. Now I can 
definitely imagine a user looking at the online doc, checking how to make a 
text bold, and figuring out that there are *two* SetBold() methods ! "Which 
one should I use ?" "Why ?" "But I can still get the mapper from the 
vtkTextActor, are you sure actor->GetMapper()->SetBold() does the same as 
actor->SetBold() ?". etc.



--
Sebastien Barre