[vtk-developers] vtkCocoaRenderWindow qq

[Francois Bertel]

Are talking about changing the vtkCocoaRenderWindow only or the
superclasses as well?

If it is only the vtkCocoaRenderWindow, it does not sound like a big deal to me.

The mechanism is to keep the existing methods and mark them as
obsolete with some macros defined in VTK/Common/vtkSetGet.h

An example of this is VTK/Filtering/vtkViewport.h/cxx:

AddProp() has been deprecated in favor of a new AddViewProp (to avoid
conflict with some Windows macros)

vtkViewport.h:

// Description:
  // @deprecated Replaced by vtkViewport::AddViewProp() as of VTK 5.0.
  VTK_LEGACY(void AddProp(vtkProp *));


vtkViewport.cxx:

#ifndef VTK_LEGACY_REMOVE
 void vtkViewport::AddProp(vtkProp* p)
{
  VTK_LEGACY_REPLACED_BODY(vtkViewport::AddProp, "VTK 5.0",
                           vtkViewport::AddViewProp);
  this->AddViewProp(p);
}
#endif

On Thu, Oct 2, 2008 at 10:12 AM, Sean McBride <sean at rogue-research.com> wrote:
> On 10/1/08 7:24 PM, Clinton Stimpson said:
>
>>Anyway, can we change vtkCocoaRenderWindow, or do we need to leave it alone?
>>I can use additional #ifdefs if we need to leave it alone.
>
> Anyone from kitware have any thoughts?  What is the policy on changing
> the meaning of public APIs?  The change would break my app and the
> SimpleCocoaVTK example (and probably OsiriX), but it wouldn't be hard to fix.
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>



-- 
François Bertel, PhD  | Kitware Inc. Suite 204
1 (518) 371 3971 x113 | 28 Corporate Drive
                      | Clifton Park NY 12065, USA