Re: Sticky popup menus

Brian <bgriffin@model.com> writes:

> You have to break down the sequence of events to see that it is not a timing
> problem. What's happening is that the menu gets posted such that an active
> menu entry is under the mouse pointer as a result of the <ButtonPress>
> event. Next, the posted menu takes over and its event bindings are in
> effect. The <ButtonRelease> will perform it's required action of invoking the
> active entry under the mouse.

Yes, I know that is exactly what is happening. And I call that a timing
problem!

When you press, hold, and release to select an entry, that is the
desired and normal action.

When you click, but some entry is selected immediately and the menu
is never even visible, then that is the erroneous behaviour.

The *only_difference* between these two scenarios is the timing
-- how much time elapses between press and release. Therefore,
it *is* a timing problem.

> The "bug" is that the menu should never ever be posted under the mouse;

Why? There is nothing intrinsically wrong with posting a menu
under the mouse pointer. In fact it may be desirable to put
some particular (default or previosly-selected) menu item directly
under the mouse. The only reason think the positioning is buggy
is because it reveals the timing problem.

I admit, taking a broader view takes us away from timing and into
event representation... If there were distinct events for "click"
and "drag" there'd be no misapplied ButtonRelease. However, Tk
has a lower level model of mouse-click events...botton down, button
up...

I'm not advocating a higher-level "cooking" of mouse-button events
though, because that introduces bad delays in processing. (So
I guess that takes us back to it being a timing problem :-)

> I'm 99% certain the "placement" issue for menus has been fixed in 8.4.6.

It was improved, but not fixed.

-- 
Donald Arseneau                          asnd@triumf.ca