FVWM: Post-popup pointer positioning issue with tall menus

[Glenn Golden]

--
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.

[Dominik Vogt]

Post by Glenn Golden
--
FVWM version: 2.6.5
Minor consistency issue regarding the behavior of relatively tall menus, when
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,

...

Post by Glenn Golden
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.

Well, fvwm always forces menus to be completely on screen as it
has not way of moving existing menus around. If you click on the
bottom pixel line of the display, you'll obviously want the menu
visible and not sticking downwards into the next page.

Have you tried the WArpTitle option?

Mouse 3 R A Menu fooMenu Mouse WarpTitle

It warps the pointer to the first menu item. It might be slightly
annoying as it warps the pointer even if that would not be
necessary, but if it's good enough, I see no reason to change the
code.

Post by Glenn Golden
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.

This is really not an option. Menus depend on being completely on
screen.

Post by Glenn Golden
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.

See above.

(d) Extend the WarpTitle option to "WarpTitleIfNecessary. This
would warp the pointer only if the menu did not pop up at the
desired item.

Ciao

Dominik ^_^ ^_^

[Dominik Vogt]

Post by Dominik Vogt
Have you tried the WArpTitle option?
Mouse 3 R A Menu fooMenu Mouse WarpTitle

That should be

Mouse 3 R A Menu fooMenu WarpTitle

of course.

Ciao

Dominik ^_^ ^_^

[Glenn Golden]

--

Post by Dominik Vogt
That should be
Mouse 3 R A Menu fooMenu WarpTitle
of course.

Thanks, Dominik, that does indeed work.

Honestly though, the man page sows a good deal of confusion on this topic.
Permit me to grouse a bit.

First, there is some syntax ambiguity: In fvwm.1, the synopsis for the "Menu"
positioning parameters is given as

[context-rectangle] x y [special-options]

with WarpTitle listed under "special-options". Based on this synopsis, the
expectation would be that if one wishes to specify a special-option, it must
be preceded by at least "x y" and optionally by a context-rectangle as well.
But the last sentence in the "Menu" section says

Note that the special-options do work with a normal menu that has no
other position arguments.

which contradicts the synopsis. If the synopsis were changed to

[ [context-rectangle] x y ] [special-options]

this would bring it into agreement with that final sentence (and really
eliminate the need for that sentence at all).

Second, there is some ambiguity regarding the functionality of WarpTitle.
The subsection describing WarpTitle seems to imply that it applies only to
submenus, not to root menus. This was also evidently Thomas' understanding too,
at least in FVWM 2.6.0. The following thread (pertaining to 2.6.0)

http://comments.gmane.org/gmane.comp.window-managers.fvwm.devel/4458

contains this comment:

Thomas Adam | 6 Jan 2010 22:52

Post by Dominik Vogt
WarpTitle only works on submenus, not the root menu.

Has the functionality been changed since 2.6.0? I quickly looked thru the
release notes for subsequent versions, but didn't see anything on this, though
perhaps I missed it. In any case, the present (2.6.5) man page certainly gives
the impression that it [still?] applies only to submenus.

Also, the name "WarpTitle" seems to be a misnomer, since it implies that the
pointer is warped to a title. In your reply, you gave an alternative
interpretation

Post by Dominik Vogt
[WarpTitle] warps the pointer to the first menu item.

But neither appears to be accurate. The functionality I observed in a few
quick experiments is that the pointer is warped to the top position of the
menu, regardless of whether that position is occupied by a title or by a
selectable menu item. Even in the case where a menu contains a Title, but that
Title is not located at the top, it still ignores the Title and warps to the
top menu entry. In short, as far as I was able to determine, the "warping"
that is performed by this option has nothing to do with any notion of "title".
In view of this behavior, a name like "WarpToTop" might be more appropriate.

On a slightly different topic: You mentioned that the code embeds the
requirement that menus must always pop in a position such that the entire
menu is visible on the current page. I have no argument with that constraint,
it seems entirely reasonable. But I would opine that it is not necessarily
"obvious" that one obtains this behavior in view of the documentation, per

Post by Dominik Vogt
If you click on the bottom pixel line of the display, you'll obviously
want the menu visible and not sticking downwards into the next page.

To me, the only thing that is "obvious" is that the code behavior and the
documentation should agree. Presently the documentation makes no mention of
this "entirely visible" constraint, and therefore one could just as well opine
that the reader's expectation is "obviously" that the menu will be placed
where he specified it to be placed.

A straightforward but effective improvement to the positioning language might
be to simply state explicitly that the position information supplied for Menu
and Popup commands should be interpreted strictly as hints or requests, since
in many common cases it winds up being overridden by the "entirely visible"
constraint (and not just in the "tall" case that I had come across.)

Summary of all the above: The documentation for menu positioning could really
use some rework for clarity. Perhaps I'll take this on later in the summer.

In any case, despite the grousing, an earnest "thank you" for pointing out
the solution to my issue. Very happy to have that behavior back again.
Small detailed abilities like this are what make FVWM a pleasure to use.