[Paraview] Reguarding python question

[Berk Geveci]

OK. You guys managed to make me put aside all the "important" work I am
doing and think about this :-) Here is my 2c

1. ParaView is not that heavily dependent on Tcl. Specially, with the
changes we have been making in the last 6 months or so (and still
continuing), it should not be too much work to replace Tcl with anything
we want (and I personally try to keep the code I write flexible enough
to allow this). It is important to keep in mind that "ParaView is
written in C++".

2. ParaView GUI is dependent on Tk. I personally do not like Tk
(including Tkinter in Python). I like Qt. I hate Qt's license. Not
necessarily for our own commercial projects but for open source
projects. We usually reject depending on anything that is GPL'd because
it restricts our commercial usage. Qt is similar in the sense that it
would restrict us. So if I had a vote, I'd definitely cast it against
Qt. I am definitely more in favor of wxWindows. However, I have very
little knowledge of it (much less than Qt and Tk) and have not been
convinced that it worth switching to. Please keep in mind that we have
SIGNIFICANT effort invested in KW widgets and switching would mean
serious work.

>     RF> I would very much like to see Python (and Qt) (PyQT?), become
>     RF> the foundation for ParaView.  I'm not adept at Tcl/Tk, and
>     RF> since it's dying, and I don't have much desire to become adept
>     RF> at it.  That limits what I can do to customize ParaView for
>     RF> myself.

ParaView's foundation is C++. It will always be so. C++ might be dying
but I think it will outlive ParaView (and if it doesn't, we'll adapt).
Tcl is the current scripting solution. However, as I said before, this
is not hard to change.

>  2. I agree that Tcl/Tk is dying.  But from what Berk said, there will
>     be a nice enough interface for others to step in.  It takes time
>     to get to a point with a design.  With a decent enough
>     model-view-controller design you get best of all the worlds.  I'm
>     not sure kitware wants to go down the Python side since they like
>     and are used to Tcl a whole lot more.  Thats sad because from what
>     I have seen Python is a better language for scientific computing.
>     Of course, I am biased.

I personally like Python whole lot more. I think that it is easier to
use, cleaner, more flexible and very commonly used in scientific
computing community. Whether this makes it a better scripting language
for the ParaView GUI is debatable. I think that it is a better scripting
language for the ParaView core (server manager).

> I'm sorry to sound typically blunt and harsh.  From what I have seen
> so far, you are only going to get a free OSS tool written in
> Python/Qt, if I sit and write it. ;-D If not, you get a great Tcl
> based one from Kitware.  Or if you insist on Python, live with a
> simpler tool that does not handle large data in parallel (but works
> quite well for small data).  If you want to improve that project, help
> out.  If you think otherwise, show me the code and where the heck were
> you all these years? ;-)

I have to correct Prabhu here. The Sandia and LANL folks ARE ParaView
contributors. They have put money, time, effort and in my opinion much
more importantly heart in ParaView. 

> Luckily for me ParaView is not implemented in Python.  If it were, I'd
> have to find myself a new hobby. ;-)

I am a fan of diversity. Honestly, I love to play with MayaVi, VisIt,
ChomboVis and to borrow ideas from them. It would probably be more
efficient if we were all focusing on one tool but not necessarily as
creative. Having different tools that grow independently allows for
different ideas to grow without being tied by a common architecture.