[haiku-development] Re: Tool Tip B_MOUSE_IDLE message handling needs better fix, help appreciated

  • From: John Scipione <jscipione@xxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 16 Dec 2013 15:43:42 -0500

On Sat, Dec 14, 2013 at 3:45 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> Am 14/12/2013 19:59, schrieb John Scipione:

Thank you for this very detailed response.

> Well, let's do this one step at a time:
> 1) The app_server always sends the coordinates in screen coordinates. It
> does not care about view coordinates.

I suspected that app server works only in screen coordinates but was
not sure if there was some way to do the conversion to view
coordinates on the app server side. This answers my first question
succinctly, there's no way to send view coordinates from app server
which makes sense.

> 2) It also does not care about the target view, or if all views will get the
> message or just one. It will always just send a single message, and that's
> why it just can't care about view coordinates.

Also makes sense.

> 3) Before a window can hook into DispatchMessage(), the message will be read
> in the task_looper(), unpacked (ie. duplicated for the different receivers),
> and then sanitized by the method mentioned above.

Somehow I got the line number messed up and I thought you were
pointing to ConvertToScreen(), I see L3471 of Window.cpp points to
_SanitizeMessage() which makes everything else you said make a lot
more sense.

> 4) That method knows how to deal with several message types, and will do all
> the hard work of converting the screen coordinates to the coordinates of the
> target view.
> 5) So, all what's left to do for you is to add a case for B_MOUSE_IDLE in
> _SanitizeMessage(), and the client code won't see a difference.

Yeah I see that, that seems like the perfect solution, catch the
message in BWindow and do the coordinate conversion before it gets to
the target view.

> Since we introduced B_MOUSE_IDLE in the first place, we could just define
> that it sends out screen coordinates, too, but this way it would be more
> consistent with the rest of the API, and easier for the view to handle.

I think this was simply an oversight on jua's part that is thankfully
now being corrected.

Thanks for your patience and all your help on this.

John Scipione

Other related posts: