[interfacekit] Re: Helping out

2007/8/7, Christof Lutteroth <lutteroth@xxxxxxxxxxxxxxxxx>:

Hi Christof,

first of all, you need to know a couple of things:
I am the one who wrote most of the BMenu classes, and I followed the
BeOS design very closely.
Unfortunately we can't change their design, because it will break
every application which subclasses menus, or even uses them in a
slightly "special" way.

>
> The BPopupMenu of the BMenuField indeed did not have the input focus
> because the window containing it had flag B_AVOID_FOCUS set.

This is intented, because the menu windows don't have to steal the
focus from the active window, and that's the flag the menu windows
have in BeOS.
I think we have to add some special support for menu windows within
app server. I don't have yet a clear idea on how to handle that. But
we can't just treat menus like any other view or window.

>
> Actually, I would like to refactor the Menu-related classes a bit. I
> found them hard to understand. I am not sure if this is the right thing
> to do, but in the long run, I would like to replace the polling
> mechanism that is used for tracking by an event-driven mechanism. I
> assume there are all the different kinds of mouse events in in BeOS,
> such as MouseOver, maybe even Enter and Leave, yes?

If in the long run you mean in future releases, I'm all for this, but
this will break the api, so we cannot do that before R1, at least.
To reply to your question, yes, we have MouseDown, MouseUp and
MouseMoved hooks, and MouseMoved carries informations which tells you
if the view was entered, left, or the movement happened inside the
view itself.

> Another question: I found myself adding a lot of debug_printf's to the
> code in order to track the control flow. Is there an easier way?

It's what I do too. I guess you could use gdb but I find it hard to
use, especially to debug menus.

HTH,

Stefano

Other related posts: