[vtk-developers] VTK 4.2.4 and VTK 5

Prabhu Ramachandran prabhu at aero.iitm.ernet.in
Tue Nov 18 01:28:11 EST 2003


Hi Ken,

Sorry about the tone of my previous email if it was offensive.

>>>>> "KM" == Ken Martin <ken.martin at kitware.com> writes:

    >> 1. There are Python related issues that were fixed in the
    >>    recent
    >> past.  Wrapping/Python/vtk/tk/vtkLoadPythonTkWidgets.py does
    >> not work under Python2.3 because the darned Python developers
    >> changed Tkinter behavior so that interp.getvar('auto_path')
    >> returns a tuple instead of a string.  These do not show up in
    >> the 4 tree and consequently you can't use the Tk widgets with
    >> VTK 4.  Serious pain in the neck.  Similarly there were the
    >> dlopen related fixes made to Wrapping/Python/vtk/__init__.py
    >> that don't show up in that tree.

    KM> I'm not a Python developer so I do not know what critical
    KM> python changes have been made since 4.2, but I'd be happy to
    KM> merge/update the branch files to match the CVS files. I just
    KM> need someone with Python/VTK knowledge to say "update these
    KM> few files from CVS" and I'll do it.

The trouble is I haven't kept track either.  I only remember the
dlopen and Wrapping/Python/vtk/tk/vtkLoadPythonTkWidgets.py as being
critically important.

I also added the GtkGLExtVTKRenderWindow*.py widgets contributed by
John Hunter.  I also changed the behavior of the Tk widgets so that
the focus is not grabbed "on enter" by default.  I am yet to change
the other widgets.  I would think that these are useful enough that
they should be part of 4.2.x.

    >> 2. I am not for tracking yet another branch (due to lack of
    >>    disk
    >> space and time), so am not volunteering to even make the
    >> changes on the 4 branch.  I would have appreciated if we were
    >> informed before the branch was made so I could have told you
    >> about this.

    KM> If you are planning to move forward to VTK 5 in the future
    KM> then there is no reason to be involved with the VTK4 tree. Now

Personally I have no concerns of moving to VTK 5.  My biggest problem
is letting users of VTK-Python and MayaVi have a stable and working
VTK that has all the features that they would want to use.  I
personally always build off CVS but users who sometimes never even use
VTK have to end up using VTK off CVS simply because critical fixes are
*only* in CVS and in no release.  As you mention using VTK from CVS is
not advisable.

My other major gripe is that this devel list is never told of new
releases.  Only major releases (like 4.0) are announced on vtkusers
and vtk-devel.  At no point of time am I sure of what is the latest
release.  I have to look at the web site to figure that out.  If you
did announce it please point me to an email on this list that was sent
and I'll shut up. :)

    KM> the VTK 4.2 branch of the main tree (different from the VTK4
    KM> tree) is the latest release and if there have been critical
    KM> fixes (not new features) made in VTK CVS then they should have
    KM> been reported to me (or noticed by me) so I could merge them
    KM> into the release. VTK 4.2 is the current release and is what
    KM> most/all non developers should be using. If it doesn't work
    KM> with Python 2.3 then that should have been addressed. Does
    KM> that make sense?

Yes and no.  Its a problem of miscommunication.  As I said I usually
have no clue of releases and have no idea of who is tracking what.
Everyone seems to happily make changes without the slightest noise on
the lists.  Only now was there talk of branching off before 5 with a
bunch of impressive changes but since I am already lost about what
releases are made I assumed that you'd branch off from where it
currently is.  I also am not sure if there are a bunch of Mac OSX
related fixes in 4.3?  The Mac issues are long running and I still am
not sure which release I can point someone to who wants to use
VTK-Python successfully on the Mac!  Those who do use seem to use VTK
off CVS and I am not comfortable pointing everyone to use CVS.

    >> When will 5 become stable or when will 4.4 be released?
    >> Without a serious timeline its going to be a pain for users to
    >> decide which release/version to use.  How unstable will CVS be?
    >> Checking the dashboards is too much work for the average user.
    >> Its a bit much asking users to even build VTK, asking them to
    >> track CVS is worse.  Also what is wrong with the current 4.3
    >> tree, without backwards incompatible changes?  Why not make
    >> that the default, let it stabilize and branch off from there?

    KM> My guess is that VTK 5 will become stable around the middle of
    KM> 2004. We will try to keep CVS stable but no average users
    KM> should be using CVS. The point of having the releases (4.2)
    KM> and patch releases (4.2.3, 4.2.4, etc) is to provide a tested
    KM> stable version of VTK so that people who need a working
    KM> version of VTK don't have to mess around with checking the
    KM> dashboards. The only exception to this is when someone needs a
    KM> new feature that is in CVS but not in the release. In those
    KM> cases if it is a key feature that is unlikely to cause
    KM> problems we will add it to the VTK 4.2 branch.

How do you define "key" feature?  How about the gl2ps stuff?  I asked
about it before 4.0 and it would be sad if users had to wait till 5.0
were released in mid-2004 to use it in a stable release.

    KM> Why not make a new release from what is in CVS right now?
    KM> Because the release process takes a lot of effort and the
    KM> amount of "added value" in VTK
    KM> 4.3 doesn't warrant it in my opinion. I'd rather perform minor
    KM>     updates to
    KM> the 4.2 branch and put the effort into getting VTK 5 done.

I have a suggestion.  Instead of having an old stable release and a
new unstable CVS version to deal with why not make interim snapshots
along the lines of "tested to be stable but not perfect for a
release".  Folks who need it can use these snapshots and will also get
the benefit from recent additions and improvements?

cheers,
prabhu



More information about the vtk-developers mailing list