--
FVWM version: 2.6.5
Minor consistency issue regarding the behavior of relatively tall menus, when
invoked via a mouse button. Example:
Mouse 3 R A Menu fooMenu Mouse -20p -10p
When Button 3 is clicked, if fooMenu fits vertically within the available space
between the pointer and the bottom of the root window, then the menu pops up
with the pointer located over the top menu item (suitably offset as specified
by -20p -10p) and with that item highlighted, as desired. This is a nice
convenience because it allows invocation of the first menu item by simply
clicking Button 3 then hitting <cr>.
But if Button 3 is clicked when there isn't enough space for the entire fooMenu
to fit vertically downward from the present pointer position, then it pops up
instead with its bottom edge aligned with the bottom of the root window, and
in this case the pointer winds up positioned over (and highlights) the menu
item that happens to have been beneath it vertically. This breaks the nice
idiom of "B3 <cr> = invoke top root menu item".
I did spend time studying the "Menu" and "MenuStyle" sections of the man page,
but could not come up with a means to accomplish the desired behavior in a way
that is independent of initial pointer position.
This is certainly not a big deal, but otoh, the existing behavior does seem to
conflict with the definition of the "Mouse" context-rectangle of the Menu
command, at least as I interpreted it. That definition does not mention
conditionality on initial pointer position; it seems to imply that the menu
pops unconditionally with its top-left corner at the present pointer position
(modulo any specified offsets.) There is a catch-all warning later that not all
context-rectangle definitions may apply under all circumstances, but I would
opine that if the present behavior is indeed the desired behavior, then it
would be nice to document the initial-position conditionality explicitly in
the "Mouse" subsection of the context-rectangle definitions.
Since I'm whining though, let me at least offer something constructive in the
way of suggestions on how this might be addressed, if it is even considered to
be worth addressing and not simply due to my missing how to accomplish it as-is:
a. Expand the "Mouse" context-rectangle definition so that it agrees with
existing behavior (i.e., states that the popped menu position is
conditional on the present pointer position and vertical extent of the
menu) and then add a new context-rectangle type (say "MouseSloppy") which
first attempts to act just like "Mouse", but if there is insufficient
vertical space, then it pops the menu anchored to the bottom of the root
window and warps the pointer to the top left corner of the menu (modified
by any specified x and y offsets, just as now).
b. Add an option which allows root menus to pop partially offscreen, and
then modify the documentation of "Mouse" context-rectangle so that it
states that its behavior depends on this new option.
c. Just make the behavior strictly agree with the present "Mouse" context-
rectangle definition in the man page, and perhaps even explicitly state
that this behavior implies that tall menus may pop up partially
offscreen, depending on initial pointer position.
The first two (a, b) seem like they would be more or less backward compatible
approaches. The last one would treat the issue as a bug fix (against the
documentation) and might surprise users accustomed to the present behavior.
Anyway... just trying to be helpful while complaining.
Thanks in advance for any assistance.
