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

[Sebastien BARRE]

At 16:54 13/06/00 -0400, Dave Reed a écrit:

>Is there any GUI front end for VTK out there?

There is at least three GUI's :
**************************
         - LCAvision (http://zeus.ncsa.uiuc.edu/~miksa/LCAVision.html), a 
project I was not aware of (see previous answer), but the GUI does not seem 
to fit what I'd like to see for the moment (see below),

         - vtkEditor (http://www.esat.kuleuven.ac.be/~vtkedit/), which is a 
nice OpenSource try, but not a serious concurrent,

         - Visualization Studio, by Principia Mathematica 
(http://www.principiamathematica.com/), which is commercial and run only 
for Win32, but looks good. I downloaded the demo once, but had problems to 
run it on my NT box (flickering).

The idea of building a serious GUI has been around for a while. What I'd 
like to see, as features :
**************************
         - OpenSource, and free

         - platform independent

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

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

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

As far as I know (I'seen AVS, but not used it), Amira is the software which 
is the closest to what I'd imagine as a good GUI.

Platform independent :
**************************
I've already built a VTK GUI for my own application, and here are some of 
my thoughts : developping a large project using Tcl/Tk is a pain, even with 
object-oriented front-end like IncrTcl. I know that VTK has a great Tcl 
support, I know that very nice and nifty examples might be built quickly 
using Tcl, but I do not think it's an option for a large system, even if 
it's component oriented. The "everything is a string" Tcl moto is sometimes 
driving me crazy, although I learned to love Tcl :)

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

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

         - something available for *both* Unix and NT (and OpenSource-like 
as well).

         - a toolkit that IS (and will be) supported and developed by a 
serious team, so to say a serious partner for VTK.

         - Python bindings of course.

That page : http://www.geocities.com/SiliconValley/Vista/7184/guitool.html 
is an interesting comparison of free GUI toolkits. To my opinion :

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

         - Tk, well... huhuh... the problem is not Tk, the problem is the 
Tcl part of Tk :) But python has indeed a strong Tk support through TkInter 
or some PmWidget (Python MegaWidget), but I do not know if they are still 
supported. I guess one could bypass Tcl by using Python bindings to Tk, but 
this still looks and taste like Tk, and I do not know about performance 
issues (Python calling Tcl calling Tk calling Tcl...). Anyway, I've been 
using Tk and Itk for a while, I find it a bit outdated and clumsy to some 
extensions, but I might be influenced by the fact that one can do *very* 
dirty things with Tk (and I guess that's what I've done :)

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

I guess we should compare Tk and wxWindows, it's worth a try. There is one 
big issue to solve : I do not know if there is an OpenGL support in 
wxWindows, or if we need to develop something like a TkRenderWidget or 
tkImageWidget for wxWindows...


Visual pipeline (like Visualization Studio or Amira), as well as an object 
browser
**************************
As VTK is pipeline- and object- oriented, I guess it would be logical to 
use such GUI representation : put a component on a grid or "pool", drag 
connections between components, press "Update" buttons or set automatic 
update, and so on. Look at Amira, it's very easy to use. An object browser 
should be available too, listing all objects and their properties, but this 
has been done already by some of us.

I guess there is two issues to solve :

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

         - achieve completeness (see below)

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

What I would like to see :

         - when I right-click on an object in a pipeline, or start a 
connection from this object to another, I would like to be aware of ALL 
possible connections, i.e. to what kind of objects/classes I can connect it 
to (and the name of these objects, if they are present in the actual 
"pool"), as well as subclasses.

         - when I click in an object in an object browser, I would like to 
see ALL functions that might be applied on that object, AND (that's 
important) the TYPE of the parameters of these functions, and the actual 
values (using Tcl, it's possible to access the list of one object's method, 
but NOT the parameter's type).

         That means for example that if the object has a SetLookupTable 
member function admitting a vtkLoopupTable object as parameter (OR a 
derived class), I will be able to build (and provide though the GUI) a list 
of the already-created objects of this target type and connect both objects 
very simply. This might be part of the previously discussed point, as a 
generalized pipeline concept : every functions that admit a VTK 
object/class as parameter might be seen as a "port", a way to connect to 
objects although they are not part of the whole "Update" stuff.

         Hints might be welcome to, for example if the functions admits 3 
floats that represent a RGB triple, I will be able to build a GUI component 
representing a color, or a color chooser.

Consequently : the VTK lib/API  is SO huge (have a look at the inheritance 
graph, and compound members list), there is so much functions, that I do 
not think that there is a reliable "human" way to maintain a list of all 
available connections and functions and implement that stuff one by one in 
the GUI, as little buttons that would clutter the interface after two months.

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

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


Just my 2 cents. Feel free to flame :)