[vtkusers] summary ? GUI for VTK

[Sebastien BARRE]

At 12:46 16/06/00 -0400, Mark Beall a écrit:

>A visual programming interface makes it very face and easy to construct
>visualization pipelines. There is a limit to how large and
>complex of a project this type of interface can support, but for
>simple, one-off types of things I personally think it's very useful.

+

>Don't take this to mean that I don't like VTK, we use it extensively
>to build visualization tools that we will use repeatedly (although
>we use C++ rather than TCL since TCL just doesn't scale well
>to large projects in my experience). But for one-off things and
>a user who doesn't have the time to memorize everything, it's
>just not the right tool.

I guess there are some work to be done here.

Here is my opinion (worth 2 cents), based on a couple of components.

Please forgive my english :) When I say "will", this of course means 
"might", these are just "ideas" of course, not decision in any ways.

* Classes browser :
+++++++++++++++++
         a GUI component that could display in a hierarchical/filtered way 
the whole VTK API.

         As I said before, it's not enough to rely on the scripting 
language to tell us which VTK commands are available, and which are not. 
Therefore, we may use the actual VTK parser/wrapper mechanism to build a 
VTKDb, a textual/structured list of all classes, functions, AND parameters 
names/types (see my answer to Ken).

         Therefore, we might need :

         - a class that will read that VTKDb, and hold the corresponding 
structures. It will allow us to query the available classes (list of all 
classes available both in the Db and in the current scripting language), 
query a specific class for its member functions, and query each function 
for the corresponding parameters, etc etc (ask for the list of ancestors, 
or children, etc). Of course, that class will not be restricted to VTK, 
because some of use have implemented their own component based on VTK. I 
guess they might be used too if they provide a Db corresponding to the 
intended spec.

         - a helper class that will act as a filter. The VTKDb (or other 
Db) will be huge, hence that class might be used to say : "I just want to 
use/see the actors classes, or the mappers, or the classes belonging to the 
imaging/ directory". This might be extended to "the classes specific to a 
kind of application (medical, financial, etc)".

         - a GUI component to bind the previous classes. Display the 
filtered result in a hierarchical tree (Explorer-like) or flat way, and 
just point and shoot to create an object. By right-clicking a class name we 
might display the "short description" of a class (which is easy to put in 
the VTKdb because it's also parsed by the actual VTK parser/wrapper). The 
*full* description/API might also be easy to get, by using a HTML widget 
(there is one in wxWindows) that will point to the current HTML VTK 
documentation (remotely, or locally). I'm maintaining the current doxygen 
documentation project, therefore I know what anchors should be used to get 
some HTML help given a class or function name.

         This component might be duplicated, so that multiple views of the 
Db might be used simultaneously. It might also be extended to provided two 
derived components :

                 - a "favorite viewer" : the user might drag/drop a class 
from the "class viewer" to a "favorite viewer" so that he might access to 
his favorite classes immediately. This favorite list might be persistent 
between sessions.

                 - a "history viewer" : this viewer might be maintained 
automatically to display the recently used classes, or the most used 
classes (i.e. these classes that do not need to be "favorite", but might be 
re-used in the current session).

         I guess these 3 viewers might be grouped in a tabbed "Class 
Viewers" window, in order not to clutter the workspace.


* Objects browser
+++++++++++++++++
         In a same fashion, a GUI hierarchical or flat representation of 
the objects that have been created during the session .
         There has been some work on that before, for example :
                         http://brighton.ncsa.uiuc.edu/prajlich/vtkPipeline/ 
http://brighton.ncsa.uiuc.edu/prajlich/vtkPipeline/fits.jpg

         What I'd like to see also :

                 - multi-selection

                 - group/ungroup, collapse/uncollapse : the user might 
select different components/branchs, and group them, then collapse the 
whole branch in a single component to save space, or provide a more logical 
view.


* Pipeline viewer
+++++++++++++++++
         The tricky one :) Visual Representation of the VTK pipeline.
         Needless to say that I love the one from Principia Mathematica :
         http://www.principiamathematica.com/products/pipeline_editor/index.htm

         I've got a friend working in Operational Research and Graph 
Theory, I'm gonna ask him if he could send me some (easy to understand) 
papers related to this difficult problem that is "Graph layouting". I've 
been looking through the web yesterday, and found no OpenSource package (in 
Python or else) doing such stuff. Any clues would be welcome. Some of us 
might work on that issue :) ? Algorithms will be fine, implementation will 
be straightforward :)

         I've been playing with the Canvas stuff implemented in wxWindows, 
and it seems OK to work with.

         What I'd like to see also :

                 - zoom in / zoom out : scrolling through the pipelines is 
fine, but zooming would be great also, to get an overview of the whole 
stuff, or a detailed approach. Photoshop 5 has a nice widget called 
"Navigation" (slider + a kind of cursor).

                 - group/ungroup, collapse/uncollapse : the user might 
select different components/branchs, and group them, then collapse the 
whole branch in a single component to save space, or provide a more logical 
view.

                 - multiple views of the same pipeline, or of a 
specific/isolated part of the pipeline

                 - multiple connections ability : not only these 
connections made through SetInput, GetOuput, etc., but also connections 
made through member functions that accept VTK objects as parameters


* Property inspector
+++++++++++++++++
         Another tricky one. By selecting an object in the "Objects 
browser" or the "Pipeline viewer", this GUI component would display all 
properties or functions related to that objects (by asking the VTKDb). If 
the clicked object is a collapsed group, it displays the properties of all 
components. Then clicking on a function would launch it, clicking on a 
parameter would change it, etc.

I guess there is a fair amount of work here, to provide some efficient 
hints helping to decide whether the parameter type is a color (and hence 
should be displayed as a color selector, which is more easier to manage 
than RGB components), a VTK object (and provide a popup or list of the 
available objects corresponding to that type), and so on. There is a nice 
abstraction of the mechanism in wxWindows, called wxPropertySheets.

         What I'd like to see also :

                 - global application : let's select different components : 
the property inspector would display the properties of all objects. By 
changing one property, it's applied to the selected objects that share that 
property.

                 - IMPORTANT : ability to "detach" a property, and put it 
on a "Custom Property Inspector" (let's call it CPI). This CPI would be 
used to build a kind of intermediate/personal GUI, grouping properties from 
different objects. For example, let's say that we are working on a medical 
imaging problem : we would like  to move from one image slice to another. 
We also might need to play with transparency. Or will CLUT. Therefore, it 
would  imply clicking on an object to look for the property controlling the 
slice number (a vtkImageReader ?), then switch to another object to look 
for the transparency slider, then move to the object controlling the CLUT. 
etc. Painful. Let's detach these *properties*, and put them in the CPI for 
direct access (and provide some ways to save that CPI).

Some facilities :
+++++++++++++++++
         - hints:
                 - File->Load : if we load a set of RAW files, it 
automatically build an ImageReader for example
                 - an icon to show/hide an object in a vtkRenderWindow quickly.

         - macros : ability to record a set of command (creations of 
objects, properties changes, etc.). I guess it's an important point also, 
that would allow us to build full-fledged application that could be used by 
"normal users", and not only "expert users". Expert users are computer 
scientist that will probably appreciate using the "Classes browser", 
"Objects browser", etc. "Normal users" might be medics, or less experienced 
users, that would *need* access to the same functionality in a less 
detailed way (different granularity). For example, let's add a medical 
image viewer : an expert user might love adding each objects (image reader, 
actor, vtkProp, etc) and tailoring them carefully, but a less experienced 
user would be satisfied by a "add Medical Image Viewer" macro that would 
just DO the same thing (because it's a macro), and maybe automatically 
display that component in a grouped/collapsed way in the "Pipeline/Objects 
browser". A CPI might also been automatically build by this macro. Hence, 
it would allow them to play with the toy at a different level of precision 
(but still helpful).

         - undo/redo : by embedding each change made to a property into a 
kind of Command class that would hold both the way to do it, but the way to 
undo it (by setting the property back to its previous value), we could 
build a "History" and implement undo/redo features. There is something like 
that implemented in wxWindows.

To be continued...