[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