[vtkusers] GUI for VTK (was [DEMO] amira)

[Prabhu Ramachandran]

hi,

	This seems to be a good time to get started on this project.
A lot of others have said they'd be willing to help.  I myself can try 
to do what little I can.

>>>>> "Sebastien" == Sebastien BARRE <seb-ml-a at barre.nom.fr> writes:

    Sebastien> ************************** - OpenSource, and free

    Sebastien>          - platform independent

    Sebastien>          - scriptable (i.e., integrated console so that
    Sebastien> we can simultaneously use both the GUI and the whole
    Sebastien> range of VTK functions in a programmatic way).

    Sebastien>          - visual pipeline (like Visualization Studio
    Sebastien> or Amira), as well as an object browser

    Sebastien>          - completeness and consistency (i.e., access
    Sebastien> to ALL VTK functions, and unified access, meaning that
    Sebastien> it has to be done automatically, see below).

	Your ideas sound really nice.  Another useful thing would be
to have a large set of simple and complex examples.  A newbie user
could use this tool for some rapid VTK application development.  I
find that there are a large number of folks who dont want to get into
the messy details of learning VTK etc. (It does have a fairly steep
learning curve esp. if one is not enthusiastic about graphics).
These users could easily develop their applications by using the
examples as some kind of a template.  

	The other advantage that such a tool has is that it is much
easier to learn VTK using it.  As you have mentioned below VTK is so
huge that it can be a big pain sorting thru the classes and figuring
out things.  With a builder it should be rather painless finding
things about the VTK classes.

    Sebastien> This leaves Python, which is a free, opened, modern and
    Sebastien> powerful scripting language, with builtin
    Sebastien> object-oriented support. It's also natively stuffed
    Sebastien> with lot of interesting modules and network access. I
    Sebastien> guess David Gobbi could advertise it better than I do
    Sebastien> :)

	That is great, I am a pythoner (not an advanced one though).

    Sebastien> Now for the GUI... I guess we need :

    Sebastien>          - GTK looks nice, is heavily
    Sebastien> supported/developed, but I'm not sure it has been
    Sebastien> seriously ported to Windows (without using cygwin I
    Sebastien> mean). It won't be discontinued, but who is ready to
    Sebastien> enter the GTK/KDE war ? :) I'd rather not see our
    Sebastien> task-force divided between VTKGTK and VTKKDE.

GTK: A long while back I tried without much success to integrate gtk
and vtk.  Matt Howlett took over and I believe got something working.
The biggest problem I had way back then was that GTK was developing
way too fast for my liking.  There wasnt a nice stable library that I
could use.  Every new derivative from gtk would use the latest version
which would make all the apps I ran incompatible.  I tried to use
gtk-- but the bindings were not complete.  Things are better now.  GTK
is also very well documented and the python bindings are good. But I
guess WxWindows or FLTK may be better from a portability perspective.

FLTK: I admit FLTK is light but it is rather powerful and has a great
gui builder and is well documented in terms of a useable user guide.

wxWindows: wxWindows is a more serious toolkit but it isnt as well
documented as FLTK is.  There is class documentation but that isnt
enough to get started quickly (There is no substitute to a well
written guide/tutorial).  The python bindings are much easier to
learn.  The tutorial isnt complete.  Id be glad if someone can point
me to any better documentation.

    Sebastien> => my favorite "candidate" is wxWindows :
    Sebastien> http://www.wxwindows.org/, but I've NOT been playing
    Sebastien> with it for the moment. It looks serious, and seems
    Sebastien> easy to install. "It'a free C++ framework supporting
    Sebastien> Windows 3.1/95/98/NT, and Unix with
    Sebastien> GTK/Motif/Lesstif. A Mac port at version 2.0 is
    Sebastien> available.  Other ports are under consideration." It
    Sebastien> has Python support : http://wxpython.org/.

    Sebastien> I guess there is two issues to solve :

    Sebastien>          - implement "serialization" in VTK, i.e. a way
    Sebastien> to save/load/store/restore objects (not scene) and
    Sebastien> their parameters in files, and therefore whole
    Sebastien> pipelines too (object by object, or by following the
    Sebastien> pipeline graph). Maybe a vtkSerialize class, and
    Sebastien> subclasses that would help objects to store themselves
    Sebastien> in different forms : portable and readable textual
    Sebastien> form, compressed binary form, Tcl form, Java form, C++
    Sebastien> form, so that by building a pipeline in Tcl, one could
    Sebastien> save it in a file as a readable C++ pipeline, and
    Sebastien> vice-versa (restore it from a C++ example, even if it
    Sebastien> is called from a Tcl program). It's not too difficult
    Sebastien> to do in Tcl, but I think it has too be natively
    Sebastien> implemented in the VTK C++ API.  (I'm quite sure
    Sebastien> Serilalization has been done also by some of you,
    Sebastien> please feel free to give some feedbacks).

	Seems to be the logical direction to take.  

    Sebastien> Completeness and consistency ****************** Meaning
    Sebastien> : access to ALL VTK functions (keyword : ALL :)). And
    Sebastien> access in a unified way.

	Yeah, but lets get started in a small way first. :)

<snipped off features - I agree whole heartedly to all of them>

    Sebastien> Therefore, I think we might need a tool that will parse
    Sebastien> the VTK sources, and build a kind of database (or
    Sebastien> listing) of all objects, functions, and parameters
    Sebastien> (VTKDB). This file would be read by the GUI, and used
    Sebastien> to build a database and provide a reliable and unified
    Sebastien> way to connect objects, or implement a full-featured
    Sebastien> object browser. It could be available for download, or
    Sebastien> updated remotely or locally when you update your VTK
    Sebastien> version, whatever.

	Sounds fabulous.  Just what I was thinking.

    Sebastien> That kind of parser is already available in some form,
    Sebastien> it is (they are) used to build the API bindings between
    Sebastien> the C++ lib and Python, Tcl, Java, and stuff. There is
    Sebastien> one parser per language, and correct me if I'm wrong,
    Sebastien> the C++ source is parsed for *every* language to build
    Sebastien> the binding. To be honest, I've not reverse-engineered
    Sebastien> the parser for the moment, it looks a bit freaky
    Sebastien> (Yacc/Bison or something like that, I'm just a poor
    Sebastien> Perl adept).  Maybe it would be a good opportunity to
    Sebastien> write a tool unifying and simplifying the stuff :
    Sebastien> something that would build that previously described
    Sebastien> VTKDB, then simple functions that would generate the
    Sebastien> bindings from the VTKDB, without re-reading the source.

	I guess you do already have a rudimentary parser in your
doxygen perl scripts?

	Are you folks going to create a separate mailing list or
something like that?  So what are we going to call the tool? 

	VTKBUILDER??

	Id like to help with this project and would appreciate if you
could let me know what you'd like me to do.

prabhu