[vtk-developers] RE: VTK Widgets redesign

[Kitware (W.S.)]

Hi Andrew-

At 09:45 PM 9/1/2005, Andrew Maclean wrote:

>1) I think mediation is going to be a major problem in the future. I foresee
>lots of widgets operating together and I think that there needs to be some
>mechanism to provide a set of rules for their interaction. Whilst I
>appreciate that there is no funding at present, perhaps in the interim, a
>simple abstract mediator class could be introduced at this stage to be
>filled out later. I guess I have a concern in that routing messages to/from
>the selected widget needs to take into account intervening/overlapping
>widgets. So there needs to be some knowledge of what widgets have been
>instantiated. Perhaps the mediator class tracks this. Anyway it is just a
>thought.

You are absolutely right. Unless we limit the number of widgets to 
one at a time, this is a big problem if we are going to create 
professional apps. Having said that, I am contemplating several 
ideas. For example, Ken Martin had a clever idea to set up callbacks 
with different priorities, this could be used to manage cursors, etc. 
However, it won't work for overlapping widgets. Also, I think this 
situation is somewhat analogous to our experience with the VTK 
pipeline, where we allowed the process of pipeline execution to be 
distributed through the data and process objects, eventually mucking 
these classes up and limiting what we could do with the execution 
model. After excessive pain to us and our community, we finally came 
out with a solution that explicitly breaks out the process of 
managing execution. With regards to the widgets, I think we are in a 
similar situation, IMHO we need some sort of an explicit mediator, 
etc. that can handle cursor management, overlaps, and event 
conflicts. Here are some of the issues:

+ What to do about overlapping widgets, either 2D that deal with 
display coordinates, or 3D, where picking is often used to select 
widgets. These are usually constrained geometrically somehow, and can 
be resolved geometrically in combination with priority, layer number, etc.
+ How to funnel events to just one widget once it's active. I am 
annoyed when I start interacting with a widget and "accidently" throw 
an event that causes the interactor style to do something. Or start 
an event sequence in an interactor style and then have the widgets 
catch the last part of the sequence (mouse up, etc.)
+ What about widgets that take over the whole display window or 
renderer? (so only one widget can be active at a time). For example, 
I may be measuring or dropping seed points, and the widget is not 
limited geometrically.

And there are probably more. I may take an initial crack at 
something, but I suspect it will have to evolve over a long time.


>2) Regarding the API between the widget and its representation - I can't see
>a more general way of doing this.

Getting this interaction right is really tricky, it's hard to 
document, and managing the state between the widget and its 
representation is challenging. But it is nice to be able to plug 
different representations in without having to redo all the event 
handling that the widget does, not to mention the benefits to 
parallel processing, etc.

Will