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

[Gavin Tabor]

I don't know if this is of interest, but I have been developing a
postprocessor for a research CFD code blending VTk with Qt, a
component-based widget toolkit written in C++. The core problem 
of linking the two has already been delat with, with a
package called vtkQGL, see 

http://www.medinf.mu-luebeck.de/~ehrhardt/vtkQGL/vtkQGL.html

so all I'm doing is sticking together buttons to produce the
effect I'm looking for. Its not the same as a general GUI builder
like Principia Mathematica or AVS produce, but its looking good
for a research CFD code.

Just my 2 kopeks...

Gavin

Sebastien BARRE wrote:
> 
> 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 :)
> 
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> vtkusers mailing list
> vtkusers at public.kitware.com
> http://public.kitware.com/mailman/listinfo/vtkusers

-- 

Dr. Gavin Tabor
School of Engineering and Computer Science
Department of Engineering
University of Exeter