BMenuField not starting in sticky mode (easy)

[wkornewald]

We used trackTime to work around this, but it wasn't very reliable (see #615).

The BMenuField menu now opens directly under your mouse pointer, so when you release the mouse button the menu closes directly because it started in non-sticky mode.

We should probably always start BMenuField menus in sticky mode and only switch to non-sticky mode if the mouse was moved a minimum distance.

[jackburton]

There's a (unused, for now) fTrackNewBounds member in BMenu. Maybe we can use/abuse it in some way to fix this problem ?

[wkornewald]

I'm not sure. I think we should use Track()'s clickToOpenRect (fExtraRect). I have problems understanding BMenuBar::TrackTask:

In BMenuField::MouseDown we call BMenuBar::StartMenuBar with a rect (specialRect=Bounds()), but in BMenuBar::TrackTask and BMenuBar::Track we seem to never use that rect. I think that with the rect it might work correctly, but the BMenuField's BMenuBar must propagate the rect one level down to the submenu which opens immediately when clicked on the BMenuField, so the specialRect is never taken into account. Is that right?

Originally, I had thought that BMenuField uses a simple BPopUpMenu instead of a BMenuBar. That way, we could easily specify the specialRect directly. Why do we not use a BPopUpMenu?

[jackburton]

Replying to wkornewald:

I'm not sure. I think we should use Track()'s clickToOpenRect (fExtraRect). I have problems understanding BMenuBar::TrackTask:

In BMenuField::MouseDown we call BMenuBar::StartMenuBar with a rect (specialRect=Bounds()), but in BMenuBar::TrackTask and BMenuBar::Track we seem to never use that rect. I think that with the rect it might work correctly, but the BMenuField's BMenuBar must propagate the rect one level down to the submenu which opens immediately when clicked on the BMenuField, so the specialRect is never taken into account. Is that right?

Originally, I had thought that BMenuField uses a simple BPopUpMenu instead of a BMenuBar. That way, we could easily specify the specialRect directly. Why do we not use a BPopUpMenu?

Because BMenuField _accepts_ a BPopUpMenu (or any other kind of menu). It's only a container. How would you use a BPopUpMenu to track a menu ? Can you elaborate on that ? Beside this, the BMenuField api exposes the internal BMenuBar so I can't see how we would change this without possibly breaking some apps.

[wkornewald]

Sorry, I wasn't really thinking in therm of API compatibility. I just thought that a menu field does nothing more than open a pop-up menu on mouse press and send a message if an item was clicked.

If the BMenuField is actually needed we probably have to find a way to pass the clickToOpenRect/specialRect to the first menu which opens when you invoke the BMenuBar.

[jackburton]

fixed in hrev19827

[wkornewald]

Cool, thanks!

[leavengood]

The problem is now when you click-and-hold on a BMenuField and then release the mouse over an item, the item is not selected and the menu stays open. I should probably open another bug for this. I'd try to fix it myself but that code is hairy!!!

[wkornewald]

Stefano, could you please have a look?

[jackburton]

Replying to wkornewald:

Stefano, could you please have a look?

Yes but not right now.

[wkornewald]

Thanks! When I have the time I'll try to find the problem, too.

[jackburton]

Replying to wkornewald:

Thanks! When I have the time I'll try to find the problem, too.

Actually I'm pretty sure I know where the problem is. The problem is how to implement it without breaking everything else :) And the code is that bad also because of the design of the class. I'm pretty sure be's code was ugly too.

[wkornewald]

Maybe we can tag easy tickets this way...

[jackburton]

it's fixed in hrev21330.