Re: [gef-dev] SWT / Draw2d Events

[Randy Hudson <hudsonr@xxxxxxxxxx>]

Manuel,

Here the method from FocusTraverseManager in draw2d that is causing you
problems.  The last line I'm pasting here is the bottleneck.

public IFigure getNextFocusableFigure(IFigure root, IFigure prevFocus) {
      boolean found = false;
      IFigure nextFocus = prevFocus;

      /*
       * If no Figure currently has focus, apply focus to root's first
focusable child.
       */
      if (prevFocus == null) {
            if (root.getChildren().size() != 0) {
                  nextFocus = ((IFigure)root.getChildren().get(0));
                  if (isFocusEligible(nextFocus))
                        return nextFocus;
            } else
                  return null;
      }

      int siblingPos =
nextFocus.getParent().getChildren().indexOf(nextFocus);

Some history on figure focus...

The idea of having focusable figures for keyboard support was added very
early on in GEF development (in 2000).  It is still used in the GEF
palette. But once the requirement for accesibility had surfaced, there
weren't enough resources to make both draw2d and GEF fully accessible to
screen readers and keyboard support.  Also, it's not clear that GEF could
do anything but completely override any draw2d notion of selection/focus,
in favor of its own viewer's selection and focused editparts.  And since
more than 95% of clients are using GEF, the draw2d effort took a back seat.

What to do?

This is open source! Contributors like yourself are invaluable at reporting
problems like performance. But for some reason, the eclipse.org community
as a whole seems to stop at this point more than (I imagine) other open
source communities. A process exists for submitting patches! This greatly
improves the chance of the problem being fixed (I know from first-hand
experience that patches can be ignored).  The above method is doing nothing
more than tree traversal of the figures.  Specifically, pre-order (parent
first) traversal.  If you can't easily short-circuit the entire search of
the tree, then you could provide a patch that either adds API to do so, or
a patch to improve the performance.  The index "siblingPos" is easily
known, but it's just not being passed along. The recursion could be
eliminated, but probably doesn't need to be.

At this point, you should open a bugzilla for further discussion.  I don't
see an existing bug.  Thanks!
-Randy