[vtk-developers] [vtkusers] VTK 4 compatibility removal - update

Bill Lorensen bill.lorensen at gmail.com
Thu May 12 15:16:15 EDT 2011


A final observation (I have to cut my lawn...)

I started a project in January to keep Slicer4 up-to-date with the ITKv4
project. I found it surprisingly easy, but, only because I had a pretty good
understanding of Slicer and ITK. Fortunately, Slicer4 can be configured with
a custom ITK. I think the same holds true for VTK. I did have to make some
ITKv4 specific changes to Slicer4 and also some changes to ITKv4 itself. So
far, Slicer4 can be built (and it is built nightly) with ITKv3 and ITKv4.

BTW, Slicer4 builds with ITKv4 after modularization. ITKv4's modularization
represents a dramatic change in ITK's organization.

This experience illustrates the ITK community's dedication to respect ITK
customers' investments. I'm confident we can provide the same level of
respect for VTK's customers.

Bill

On Thu, May 12, 2011 at 3:03 PM, Bill Lorensen <bill.lorensen at gmail.com>wrote:

> As Steve suggested, there should be some work done at Slicer Project week
> to begin the transition from the old VTK4 way of doing things to the VTK5
> way. I suggest a project to deal with this. I think that there will be many
> no-brainer conversions sprinkled with difficult ones. A Slicer4 project
> dealing with the no-brainers sounds like a reasonable project. Maybe Berk
> could attend. It's a short drive. It would be educational for all.
>
> We should start a list of conversions, e.g.
> SetInputConnection/GetOutputPort and GetWholeExtent. Berk implies that these
> can be easily done with a script.
>
> I wish I could be there this summer, but too many conflicts...
>
> Bill
>
>
> On Thu, May 12, 2011 at 2:52 PM, Berk Geveci <berk.geveci at kitware.com>wrote:
>
>> The changes that I am making will live on its own branch for a while -
>> I suspect 2-3 months.
>> I'd recommend making the necessary fixes to Slicer master during that
>> time. That way, by
>> the time I merge, there would be no need to change Slicer. And this
>> would prevent any
>> divergence of code. This would probably require regularly merging from
>> VTK master to
>> my branch (or at least some sort of integration branch) and that can
>> be arranged.
>>
>> -berk
>>
>>
>> On Thu, May 12, 2011 at 2:35 PM, Steve Pieper <pieper at ibility.net> wrote:
>> > Hi Guys -
>> >
>> > An informal poll of slicer developers the other day raised a lot of
>> concerns
>> > along the lines Bill is raising.
>> >
>> > For slicer 3.x, our current release, we can stick with vtk older
>> releases so
>> > that's not a problem.
>> >
>> > But for slicer 4.x, Jc and Julien have been trying to keep slicer's
>> version
>> > of vtk (https://github.com/Slicer/VTK) pretty close to the vtk master
>> since
>> > there's a lot of joint development on charts, widgets, volume rendering
>> and
>> > so forth.  Once Berk's changes go into the vtk master, the Slicer/VTK
>> > version will end up diverging until the few thousand issues Bill found
>> can
>> > be dealt with.  This is not ideal, but probably manageable for a while.
>> >
>> > -Steve
>> >
>> >
>> > On Thu, May 12, 2011 at 2:16 PM, Bill Lorensen <bill.lorensen at gmail.com
>> >
>> > wrote:
>> >>
>> >> Berk,
>> >>
>> >> I realize that the ARB did talk about this. I suggest that after you
>> >> finish your pass through VTK and Paraview, that you describe your
>> experience
>> >> to the ARB so that we can understand the impact on VTK customers.
>> >>
>> >> Bill
>> >>
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110512/9b7de949/attachment.html>


More information about the vtk-developers mailing list