[haiku-appserver] Re: [Haiku-commits] r12082 - haiku/trunk/src/kits/interface

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 29 Mar 2005 14:27:30 +0200 CEST

Michael Lotz <mmlr@xxxxxxxx> wrote:
>  > For B_KEY_DOWN, BWindow will first handle this message in
>  > DispatchMessage to intercept TAB, SHIFT+TAB, OPTION+TAB, etc 
> > keystrokes
>  > to that it would advance to the next focus item/group. It is after 
> > that
>  > check that it calls fFocus->KeyDown(); Same goes for the menu and
>  > DefaultButton.
> You have your BWindow which has a BView attached where you track 
> with the KeyDown hook function. This works well for almost all cases. 
> But if you 
> want to write a Terminal application, you will need to get those 
> B_TAB keys too.

Actually, this is not correct; the basic idea is, but the B_TAB key is 
(like all other keys) supposed to get through to a normal KeyDown(). 
The view itself is responsible to trigger the navigation (as stippi 
correctly remembered) - AFAICT the window only handles the control 
group navigation.
IOW our implementation seems to be wrong - but please check before you 
trust me :-)

> later should go to the filter function, plus those who would normally 
> be dispatched by 
> BWindow like the B_TAB.

Again, that's not correct. BWindow dispatches key events in 
DispatchMessage() and makes sure that all command keys are filtered 
out, etc. B_TAB comes definitely through.

> Look at MiniView.cpp in src/tests/apps/miniterminal for the 
> implementation. This way it 
> works under R5 as it should and we get the following if we hit 
> debugger from the filter 
> function:
> w>MiniTerminal:sc
>     frame         retaddr
> fd039c18   8000608e  MiniView::MessageFilter(BMessage *, BHandler **, 
> BMessageFilter *) + 
> 0000002e
> fd039c58   ec199012  BLooper::apply_filters(BList *, BMessage *, 
> BHandler *) + 000000e2
> fd039c88   ec19a8ab  BLooper::top_level_filter(BMessage *, BHandler *
> ) + 00000087
> fd039cac   ec25307e  BWindow::task_looper(void) + 000003a2
> fd039d28   ec19ae46  BLooper::_task0_(void *) + 00000036
> fd039d3c   ec06c50d  thread_start + 00000039
> w>MiniTerminal:
> This tells us, the BWindow::task_looper got the message, called 
> apply_filters and found 
> the filter we added to our BView and called it's function.

Note that this only applies if the target handler is known at this 
point. If all handlers are asked subsequently, the message filter must 
still be applied, which is not yet done (I recently added a comment 
about this to BHandler::MessageReceived()).

> Without my change, we do pretty much the same thing, we would get 
> into the 
> task_looper and would call apply_filters. BUT we would not catch the 
> filter that 
> was added to our BView, because we would only check the filters that 
> were 
> applied to the BWindow itself and not to the view that will later 
> receive the 
> B_KEY_DOWN event.

A looper knows about its handlers as a windows knows its views - there 
is nothing special here; a looper must apply the filters for the 
handlers, the window itself shouldn't care.

> If we bdb the MiniTerminal from where we will find that the 
> BWindow::task_looper calls 
> BWindow::determine_target somewhere before applying the filters. What 
> I guess from this 
> now is: The BWindow finds out whether itself or the focus view will 
> be the target for this 
> event and then calls apply_filters for the actual target and not 
> itself.

Why should that behaviour be different for a BWindow (compared to a 

> For any B_KEY_DOWN or B_KEY_UP event aswell as B_UNMAPPED_KEY_DOWN, 
> B_MODIFIERS_CHANGED and B_MOUSE_WHEEL_CHANGED the focus view will be 
> the actual target, so 
> this is what determine_target returns.
> This does not break the path of the message to dispatch. Even if we 
> change the target, the 
> BWindow will get the message to dispatch, but only if we did not 
> filter it out by our 
> BMessageFilter:
> if (handler) // the determine_target one -> our MiniView
> {
>      //    Do filtering
>      handler = top_level_filter(fLastMessage, handler);
>          // filtering is applied to the BMessageFilters of MiniView
>      // if we skip the message from within the filter, handler will 
> be NULL.
>      // if we don't change the handler to something else from within 
> our
>      // filter funcation, the looper of the handler will be the 
> looper of
>      // the BWindow we are in -> this one.
>      if (handler && handler->Looper() == this)
>      {
>          // so we get here normally and can handle B_TAB from
>          // BWindow for TAB navigation.
>          DispatchMessage(fLastMessage, handler);
>      }

A filter can redirect a message to another looper? And if that's the 
case, it should probably not be eaten like done here.

> We must find out what the target will be first, only then we can call 
> the correct filters.
> I hope this clears it up a bit.

That part is correct, but for loopers too.


Other related posts: