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

Sebastien BARRE seb-ml-vtk at barre.nom.fr
Mon Jun 19 06:47:05 EDT 2000


At 09:55 18/06/00 -0400, Ken Martin a écrit:

Regarding the VTKDB (stupid name, I know :)

>A network editor for VTK sounds like a great idea. I have one suggestion, 
>use the parser that is in VTK currently.

I had exactly the same idea, and started looking at that last week. It's 
not difficult, but the hint file is not documented, and they are a couple 
of codes (301, 302, etc) that are hard to get. Hopefully, David Gobbi send 
me some insights. Ken, do you mind if I send you some private email to 
clarify the last issues ?

I just have to see what format we should use for the Db. I guess "plain 
structured text" will be fine for the moment. I'm aiming at something 
lisp/or prolog-like, because wxWindow has a robust parser which use that 
format, and it's not worse than anything else :

diagram_definition(type = "Spirit Belief Network").

node_definition(type = "Model",
   image_type = "Diamond",
   attribute_for_label = "name",
   attribute_for_status_line = "label",
   colour = "CYAN",
   default_width = 120,
   default_height = 80,
   text_size = 10,
   can_resize = 1,
   has_hypertext_item = 1,
   attributes = ["name", "combining_function", "level_of_belief"]).

etc.

Therefore, in our case, something like :

class(name="vtkFoo",
         abstract=true,
         function(name="Print",
                       return="void",
                 arg(name="message",
                       type="char*")
                 arg(name="count",
                       type="int"))
         function(name="Test",
                       return="int",
                 arg(name="message",
                       type="char*")
                 arg(name="count",
                       type="int")))

What do you think ? Add some parenthesis might help getting some 
"robustness", or recovering from corrupted data.

The advantage of using the VTK parser is, as you said, that the parser will 
always be up to date because it is used to build the bindings.

Ken, would you mind if I add a target to pcmaker.exe, so that a new 
directory called vtkdb is created (like vtktcl, or vtkpython), that will 
hold a textual description of each file/class ? One description per file, 
so that we could use the 'make' facilities to automatically rebuild only 
these descriptions corresponding to the classes that have been modified in 
the CVS. Then I might add a 'make' target to concatenate all files if 
necessary, and put the result in vtklib/vtkdb.txt ?

>That way the code & UI for the nodes will all be generated from the C++ 
>header files. Then you just need to create the supporting classes and main 
>UI etc.

True. Someone said that this approach was not simple enough, but I think 
it's crucial, we have to think "global", I think we can't implement VTK bit 
by bit, in a class-specific fashion, but rather build a general mechanism 
based on the DB.





More information about the vtkusers mailing list