--
Dominik Vogt <dominik.v...@gmx.de> [2013-06-30 17:31:50 +0100]:
>
> 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
>
> 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
>
> [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
your comment:
>
> 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.
