[vtk-developers] vtkWidgetEventTranslator -- care and feeding?

[Karthik Krishnan]

Kent:

Thanks for reporting the bug.

On 12/17/07, kent williams < nkwmailinglists at gmail.com> wrote:
>
> The documentation says any call to SetTranslation will override any
> previous call to SetTranslation.  This appears not to be the case, or
> maybe I haven't yet figured out the magic incantation yet.
>
> vtkWidgetEventTranslator *xlat =
> this->m_ContourWidget->GetEventTranslator();
> xlat->SetTranslation(vtkCommand::KeyPressEvent,
>                       vtkEvent::ControlModifier,
>                       101,1,NULL,vtkWidgetEvent::AddFinalPoint);
> xlat->SetTranslation(vtkCommand::NoEvent,
>                       vtkEvent::NoModifier,
>                       47,1,NULL,vtkWidgetEvent::Delete);


The translator now works as reported.

http://public.kitware.com/cgi-bin/viewcvs.cgi/Widgets/vtkWidgetEventTranslator.cxx?r1=1.2&r2=1.3

http://public.kitware.com/cgi-bin/viewcvs.cgi/Widgets/vtkWidgetEventTranslator.h?r1=1.4&r2=1.5

Note that it will not overwrite the existing translation, as it could (and
will break existing widgets). I can explain if needed.

However, I've just added an explicit way to remove a translation and add
your translation in...

such as:

  eventTranslator->RemoveTranslation( vtkCommand::RightButtonPressEvent );
  eventTranslator->SetTranslation(
      vtkCommand::KeyPressEvent,
      vtkEvent::NoModifier, 103, 0, NULL,
      vtkWidgetEvent::AddFinalPoint );

Let me know if this works fine.

Also, the Delete Point binding is really strange.  In the CVS version
> of the widget, hitting 'Ctrl', 'Shift', and on Mac, the CloverLeaf Key
> deletes the last point during contour definition, and the currently
> selected point after a contour is closed.  This appears to be a bug,


Yes. This is a nasty bug in VTK. With the VTK EventTranslators and
comparisons in general... I intend fixing this when I find time...

Here's an expostulation of the bug..

A keyboard event from X has a "keysym" and a "keycode". The fact of the
matter is that BOTH are needed to uniquely identify a key.
However the problem is that VTK widgets erroneously assume that just the
"KeyCode" suffices to uniquely identify them.
You've yourself written such a line above...
    eventTranslator->SetTranslation( vtkCommand::KeyPressEvent,
vtkEvent::NoModifier, 103, 0, NULL, vtkWidgetEvent::AddFinalPoint );

The NULL here instructs the translator to ignore the keysymbol.

Now, the control, alt, spacebar etc... have a KeySym, but their KeyCode is
0.

Hence when the control key is pressed, the event translators, ingore the
keycode in comparison (since its NULL, IMHO that's the first bug and the
easy one).
And comparison with any event that has a keysym of NULL yields true, by
virtue of something being null in each event. See operator== in vtkEvent.h (
http://public.kitware.com/cgi-bin/viewcvs.cgi/Widgets/vtkEvent.cxx?annotate=1.7
)

As a result comparison with the first keypress event is a success and the
widgets start doing bogus things...

We should really be using XLookUpString(..) and doing string comparisons in
there......

HTH
-- 
Karthik Krishnan
R&D Engineer,
Kitware Inc.

_______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20071217/3f8a076a/attachment.html>