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

[Brian Alexander Todd]

Dear vtkers,

There seems to be a lot of interest in a VTK / wxWindows union.
This would be a dream come true for me since I've been struggling
with this for about a year.  Some of you may be interested in 
downloading a wxVTKWindow class from

http://home.cwru.edu/~bat5/wxvtk.html

to get you started.  I've been able to render into wxWindows on
wxGTK (linux) and wxMSW.  I haven't tested the motif code which
I copied from someone elses previous wxVTK attempt.  I have a lot
of other code but it is shakey.

If anyone is willing to lead a full-fledged wxVTK project I
would be glad to support it (with time not money; I'm a grad 
student I have more of the former).

Brian





At 04:09 PM 6/14/00 +0200, 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
>
>