[vtk-developers] vtkWidgetEventTranslator -- care and feeding?
nkwmailinglists at gmail.com
Mon Dec 17 16:53:14 EST 2007
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
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
On Dec 17, 2007 2:15 PM, Karthik Krishnan <karthik.krishnan at kitware.com> wrote:
> 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 =
> > 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.
> 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 );
> 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
> 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 (
> 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
> Karthik Krishnan
> R&D Engineer,
> Kitware Inc.
> > _______________________________________________
> > vtk-developers mailing list
> > vtk-developers at vtk.org
> > http://www.vtk.org/mailman/listinfo/vtk-developers
More information about the vtk-developers