Re: findbar behaviour

Jorge Arellano Cid <[email protected]>
Newsgroups gmane.comp.web.dillo.devel
Message-ID <[email protected]>
On Wed, Dec 26, 2012 at 05:24:27PM +0000, corvid wrote:
> Jorge wrote:
> >   IIRC, a relatively clean way to hook this shortcuts is to let the
> > event get to the parent group, which in this case should focus its
> > next child.
> 
> I'm not quite sure what you're saying here...

  FLTK  tries  to  deliver  events in similar but different ways.
AFAIR, for keystrokes, when a leaf widget is focused, it tries to
deliver  there first, and if not handled, then it goes upwards to
its parent. If not handled all the way up, fltk tries "harder" to
deliver it.

  Depending  on the particular widget tree of the application and
the  internal  algorithm used by fltk, is hard to predict exactly
how this sequence goes.

  So  a simple way to resolve the problem, is to code the handler
in  the  common parent that encloses a closely related widget set
(e.g. Findbar may do it in this case).

  e.g.  let  the  event  travel  upwards to Findbar::handle(), do
what's necessary there and return non zero (i.e. "handled").

  (CustInput::handle() is a good example of this technique).

-- 
  Cheers
  Jorge.-
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.