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

[kent williams]

Here's an even more direction question -- given the 'keycode' and
'keysym' parameters, where does one find a list of possible values?

The keycode I was just guessing at -- I think I googled for an ASCII
character chart, but I don't know if that's where I should be looking.
 And what are the possible keysym strings, and where is a list of
them?

It sounds like there's some pretty intimate ties to the X11 way of
doing things, so it begs the question, how is this abstracted for
cross-platform usage?


On Dec 17, 2007 2:15 PM, Karthik Krishnan <karthik.krishnan at kitware.com> wrote:
> 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
> >
>
>
>
>
>