Mode line menus

[Chong Yidong]

Currently, the menus accessible from the mode-line (e.g. by clicking on
the major mode name) are bound to down-mouse-1.  Therefore, you have to
hold down the mouse button after clicking the menus.  Releasing the
mouse button immediately dismisses the menu, selecting the item the
cursor was on (if any).

My understanding is that this behavior is nowadays extremely
non-standard.

Nowadays, clicking on a menu button is expected to pop up a menu, which
is dismissed by clicking elsewhere or by selecting a menu item with
another click.  In Emacs, this can be accomplished simply by binding the
menus to mouse-1 rather than down-mouse-1.  (This works for both GTK and
non-toolkit builds).  The `mouse-appearance-menu' command, bound to
S-mouse-1, already makes use of this behavior.

Is anyone attached to the old behavior?  If not, I'd like to switch to
the standard behavior.

[David De La Harpe Golden-2]

Chong Yidong wrote:

> Currently, the menus accessible from the mode-line (e.g. by clicking on
> the major mode name) are bound to down-mouse-1.  Therefore, you have to
> hold down the mouse button after clicking the menus.  Releasing the
> mouse button immediately dismisses the menu, selecting the item the
> cursor was on (if any).
>
> My understanding is that this behavior is nowadays extremely
> non-standard.
>
> Is anyone attached to the old behavior?  If not, I'd like to switch to
> the standard behavior.
>
>

Hmm. with "modern" menus, you CAN still select an item by pressing down
the mouse button (displaying the menu), moving the mouse, and releasing
on a valid item, selecting the item and immediately dismissing the menu.
You don't need to click twice.

BUT if you do "click" the button (i.e. press then release before
selecting an item), the menu stays present, and is dismissed by clicking
on an item to select it,  or by clicking outside the menu to dismiss
without selection.

[Andreas Schwab-2]

Chong Yidong <cyd@...> writes:

> Currently, the menus accessible from the mode-line (e.g. by clicking on
> the major mode name) are bound to down-mouse-1.  Therefore, you have to
> hold down the mouse button after clicking the menus.  Releasing the
> mouse button immediately dismisses the menu, selecting the item the
> cursor was on (if any).

I don't see that here.

> Nowadays, clicking on a menu button is expected to pop up a menu, which
> is dismissed by clicking elsewhere or by selecting a menu item with
> another click.

This is exactly the behaviour I get.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Date: Sat, 07 Nov 2009 14:06:19 -0500
>
> Currently, the menus accessible from the mode-line (e.g. by clicking on
> the major mode name) are bound to down-mouse-1.  Therefore, you have to
> hold down the mouse button after clicking the menus.  Releasing the
> mouse button immediately dismisses the menu, selecting the item the
> cursor was on (if any).

This is toolkit-dependent, I think.  At least, on MS-Windows it
doesn't happen (i.e. the menu stays on even after you release
mouse-1).  The same happens on MS-DOS and I think with native
non-toolkit menus (on X without a toolkit) as well.

> I'd like to switch to the standard behavior.

Which is what? that you can release the button without the menu
popping down?  I won't mind that, but please make sure your code works
in a non-toolkit build.

[Chong Yidong]

Andreas Schwab <schwab@...> writes:

>> Currently, the menus accessible from the mode-line (e.g. by clicking on
>> the major mode name) are bound to down-mouse-1.  Therefore, you have to
>> hold down the mouse button after clicking the menus.  Releasing the
>> mouse button immediately dismisses the menu, selecting the item the
>> cursor was on (if any).
>
> I don't see that here.
>
>> Nowadays, clicking on a menu button is expected to pop up a menu, which
>> is dismissed by clicking elsewhere or by selecting a menu item with
>> another click.
>
> This is exactly the behaviour I get.

Interesting.  Maybe there's a bug.

I'm running a GTK build (i686-pc-linux-gnu, GTK+ Version 2.16.1) on
latest trunk.

If I do a mouse-1 click-and-release on the major mode name, most of the
time it does not pop up a menu.  Instead, I get an echo area message

"mode-line down-mouse-1-"

and that's all.  Once in a while, the menu seems to pop up and stay up.
But this happens very occasionally.

[Chong Yidong]

Chong Yidong <cyd@...> writes:

> Interesting.  Maybe there's a bug.
>
> I'm running a GTK build (i686-pc-linux-gnu, GTK+ Version 2.16.1) on
> latest trunk.
>
> If I do a mouse-1 click-and-release on the major mode name, most of the
> time it does not pop up a menu.  Instead, I get an echo area message
>
> "mode-line down-mouse-1-"
>
> and that's all.  Once in a while, the menu seems to pop up and stay up.
> But this happens very occasionally.

I just confirmed that mouse-1 pops up the menus fine on a lucid toolkit
build.  So this looks like a bug in the GTK code.

So sorry for the noise; I guess the thing to do is to fix the GTK code.
It appears that the GTK menu is popped down as soon as the mouse-up
event is sent to Emacs.  I'm not sure why this is happening, tho.

[David De La Harpe Golden-2]

Chong Yidong wrote:

> and that's all.  Once in a while, the menu seems to pop up and stay up.
> But this happens very occasionally.
>

When I do a mouse-1 -down -up -down and hold, I get a flash of the major
mode popup modeline menu, then a popup menu containing toolbar and
menubar menus containing, well, the toolbar and main menubar.

Hnuh?  I don't use the menus anyway, maybe it's a feature.

[David De La Harpe Golden-2]

David De La Harpe Golden wrote:
> Chong Yidong wrote:
>
>> and that's all.  Once in a while, the menu seems to pop up and stay up.
>> But this happens very occasionally.
>> >

Behaviour seems to vary depending on the distance of the modeline
from the bottom of my display.  If the modeline is too close to the
bottom of my display, the popup does not stay open on click.
GUI toolkits tend to treat menus close to screen edges specially
to ensure they are shown entirely on-screen, so there's certainly room
for window-location-dependent bugs.

[Chong Yidong]

David De La Harpe Golden <david@...> writes:

> David De La Harpe Golden wrote:
>> Chong Yidong wrote:
>>
>>> and that's all.  Once in a while, the menu seems to pop up and stay up.
>>> But this happens very occasionally.
>
> Behaviour seems to vary depending on the distance of the modeline
> from the bottom of my display.  If the modeline is too close to the
> bottom of my display, the popup does not stay open on click.
> GUI toolkits tend to treat menus close to screen edges specially
> to ensure they are shown entirely on-screen, so there's certainly room
> for window-location-dependent bugs.

I have checked in a fix for this bug.  The problem, apparently, is that
GTK tries to automagically determine how to pop down the menu based on
the event timestamp, which we were not passing to it.

[David De La Harpe Golden-2]

Chong Yidong wrote:

> I have checked in a fix for this bug.

Cool, gone on my sys.

I found it quite easy to popup the menu and then a tooltip that obscures
it if I paused to read the popup menu before moving to an item - i.e.
move to the major mode section of the modeline and quickly click to
popup the menu before the tooltip appears, but then wait a bit while the
popup is onscreen before moving the mouse after clicking to popup the
menu, tooltip may still appear - the Fx_hide_tip() you added only covers
the case where the tip is onscreen before the menu is popped up I think.