[haiku-development] Re: Can we do better with messages that are dispatched by the menu window looper?

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 29 Feb 2020 08:59:38 +0100

Hi John,

On Fri, Feb 28, 2020 at 6:35 PM John Scipione <jscipione@xxxxxxxxx> wrote:

If an app has a menu open then the menu window will eat messages that
would ordinarily be received by the main window looper. I'm wondering if we
can do better.

In Tracker you can hold shift to change the Identify menu item (in File
menu or file's context menu) to Force identify. However, this only works if
you push shift before opening the menu. There's a couple other menu items
that work this way too in Tracker.

I'd like to make it so that Tracker will live update the menu item when
you press and release the shift key instead, but when I try to handle the
B_MODIFIERS_CHANGED method in ContainerWindow I don't get the message. This
is because when a menu is open the menu window looper is dispatching the
messages instead and it passes the message to its inherited BWindow never
to be seen again.

The menu window looper could relay messages it dispatches to
be_app_messenger then Tracker could forward the message from the app looper
to the window looper.


I believe this is due to the behavior on focus of the user interface. That,
sort of makes sense.

My suggestion would be to try to install a BMessageFilter in the menu
window looper, and redirect the messages you are interested from there. A
subclass should suffice.

-- 
Saluti,
Dario

Other related posts: