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

[John Biddiscombe]

>>Filters can be loaded by DLL. You need to wrap them in a GUI
>
>What do you mean by "filters" ? (regarding VTK).

If you write your own filter (subclass of any vtkSource), then as a general
rule, it will 
a) accept some inputs (subclasses of DataObject)
b) generate some outputs (ditto)
c) have some parameters (usually scalar in nature).

This is a simple "Filter" and can be wrapped in a gui box in minutes by
entering some details in a little program (database thing sort of) that
generates a C++class wrapper, derived from a base class that we've
constructed here (hence you need our headers). You simply type in some
details about your filter (input types/ param types/float/int/colour/etc
etc - I'm always looking for improved widgets for making these better)
The program maintains a list of DLLs and you put your "filter" in one
(Raytracing.dll, building_databases.dll, texture_stuff.dll, etc etc). The
gui generator, creates a class file in C++, and then calls Make and build
all the gui objects into a DLL. the dll can then be loadef into RPD by a
register/load button.

Once loaded it appears in the tree of classes (filters) and you can drag
and drop it on the workspace and set the connections/parameters etc etc.

There are harder ones to wrap. Some speciality filters are not really
filters, but instead things like VolumeRayCastFunction or LookupTable
generators. Simple ones can be just wrapped, and export a this* pointer,
others I tend to design a GUI by hand and then simply stuff it into a dll
by linking with the others, but skipping the auto gui building step. In
principle all vtk classes can be wrapped up, but I haven't done them all
yet. Really just the ones I use. If I need one and it's not wrapped, then I
wrap it. (250+ done so far - although about 75->100 are our own classes)

some filters are more painful. Like ImageThreshold. I'll skip a detailed
explanation, but setting UpperThreshold overwrites Lower threshold and
thresholdbetween overwrites both, so you need to be more careful with the
auto-parameter generator, and for these filters, the gui wrapper allows you
to enter some C++ specifically in the IO box to make it work OK (it merges
this with its auto generated bits and it's really quite a clever solution :)

Subclasses of vtkProp need special treatment, as I have handled windows and
actors a little differently, so these are best done inside C++Builder and
then linked, but I'm gradually thinking that I can build a completely self
consistent framework for most classes without quite so much "fiddling" with
individual cases. ( I got fed up with mappers, properties, actors as
seperate windows and made a single actor with all encapsulated in one box).

My experiance tels me that writing a general purpose gui to encapsulate the
basic vtk workings is quite straightforward, but once you start doing it
really seriously (like wrapping it all!) , there's a lot of work. I'm
pleased with the results so far, but there's still a lot to do and I am
increasingly finding I haven't got time to do it as I have "modelling"
contracts to fulfill.

Things like the drag drop are well handled by type checking the inputs and
outputs of boxes (I had to add some stuff to vtk itself to really make it
swing - thanks kitware people). And some filters are nasty for different
reasons (eg appendpolydata because the inputs can be varied and I made some
tweaks there too - I have some more ideas, but they're not implemented yet).

>>If I can get emails from "LOTS" (I don't know how many) people, then I can
>>hopefully persuade the powers that be here to allow me to release a demo.
>
>And if I set my cron table so that you receive one email every hour, is it 
>going to be fine also ? :))
>I'd love to see a demo.

>From the "persuading people to let me release a demo" standpoint it'd be
fine, but from the "Could I generate an income from this and do it full
time" standpoint, then I'm afraid it doesn't help, and the serious question
is the latter :( 

Balls.

I posted a whine a month or so ago about "giving away code" etc etc and I'm
in the unfortunate position that, if I give stuff away, before I've
generated some income, then I'll get shot. Once you have a customer base,
you can safely be altruistic because they become dependent, I'd love to
make the whole project open-source and do it in QT or another of the cross
platform setups, but then any possibility that I can incorporate this in a
commercial venture goes a bit pear shaped (at least in the short term).


>I guess you mean "Kylix". There has been some news recently at /. : 
>http://slashdot.org/article.pl?sid=00/06/07/1255251&mode=thread

Nice. Like it like it. If they're already at the screenshot stage then I'd
better get on the beta test list.


>I do not think it's gonna be available before the end of the year, and 

I'm in no hurry really. The basic functions of the vtk/GUI environment are
platform independent. There's be some fairly painful rewriting of large
bits if it was ported, but if Borland make a component library that's
fairly well matched to their existing windows one, then it'll be no
problem. Of course, I know about as much about unix as you do about space
bats, but I don't think it'll be a major obstacle :)


not
>sure there is much C++Builder support/users for VTK (sadly). 

Microsoft have it pretty well sewn up, it's true...


>compile VTK with Borland tools some time ago, but failed, I guess I missed 
>some tweaking. As I said before, I'd rather a some scripting language + 
>portable GUI toolkit solution, but it's only my opinion.

Whilst I'm at it. Wrapping tcl around the vtk classes is no problem and
wrapping tcl around my gui stuff is also OK, but are there an good sites
with info on sticking an interpreter in a window and "managing" a
program/script.

>Looks good John. Thanks for the feedback.
Thanks for the compliment, must get out and have some lunch....

JB