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

[Dave Reed]

> From: Sebastien BARRE <seb-ml-a at barre.nom.fr>
> Cc: vtkusers at public.kitware.com
> 
> 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).


Thanks for the above info - someone else also e-mailed me about the
last one.  I'd like to hear about it from anyone who has used it since
I couldn't tell that much about it from their web site.


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



I was planning to do this - although it would be great to get some
funding from Kitware to develop it :-)



>          - platform independent


I admit I'm not interested in developing for Windows.  If I were to
develop it by myself (which would of course take years given I have to
teach 8 courses a year), I probably wouldn't bother with Windows (just
something that should work on most Unix versions and Linux).  If other
people are interested in this and willing to work with some of the
cross platform GUI toolkits, I'd be happy to let someone else work on
that.  I've written some GTK apps and know there is some kind of port
for it to Windows, but I don't know what its status is.  If gtk and
pygtk (python bindings for gtk) have been ported to Windows, they
would be a good solution for me.


>          - 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).


As I mentioned in my original message, I was planning to use Python
(or at least Python for part of it) so it would output the Python code
for the given graphical pipeline.  This would allow both the GUI and
user written Python code to be used to develop the pipeline.


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


I haven't seen those, but I think that's what I'm talking about.


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


That's the main reason I think Python is the appropriate choice - you
can ask it what all the functions are for an object.  This would be
used to automate the interface for setting the various properties.



> 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 :)


I definitely like Python even though I've used it for less than 6
months now.  I've never used Tcl.  The syntax doesn't appeal to me and
I've already got too many languages floating around in my head (C/C++,
Java, Fotran, Pascal, Perl, PHP, PostScript, Python, Scheme/Lisp, APL,
etc. :-) so I don't really have much interest in learning Tcl since
Python seems fine for the same type of tasks IMO.


> 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 :


I don't have any experience with any of the widget toolkits other than
GTK (I've also used Motif).

<info about various toolkits snipped>



> 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).


I was just thinking of storing the graphical pipeline and the settings
for each object in a graph structure that could be saved to a file.
The GUI would also produce a Python VTK program (and/or other
languages) that represents the graph.  Your thoughts are much more
versatile.


>          - 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).


My initial thoughts weren't this grand.  I was going to assume people
would have to know what connections to make themselves.  I just wanted
to provide a GUI version to make it easier to use for people with
limited programming skills/non-programmers and a fast prototyping
mechanism for programmers that could then be extended by modifying the
resulting Pythong vtk code.  But if other people want to work on it,
that's great.



>          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.


Agreed.


> 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.


I don't think this is necessary with Python since you can get the info
from it (except I don't know if there's a way to get the expected
parameters in Python).


> 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.


We may want to take this off-list unless there is a lot of interest.
Again, I really won't have time until next March or April, but decided
to ask now about exisiting solutions since someone else mentioned it.

Dave