Re: FVWM: Style * MwmButtons

From: Mikhael Goikhman <migo_at_homemail.com>
Date: Mon, 20 May 2002 21:43:00 +0000

On 20 May 2002 22:44:53 +0200, Marcus Lundblad wrote:
>
> On Mon, 20 May 2002, Mikhael Goikhman wrote:
>
> > On 20 May 2002 21:30:45 +0200, Marcus Lundblad wrote:
> > >
> > > Is there a way to get a window decor button that is tied to a menu to not
> > > remain pressed in when the mouse button is released, althogh the menu is
> > > still posted? (this is the way it behaves in mwm)
> > > Maybe this should be implied by Style MWMButtons
> >
> > With 2.5.1 (only) replace the line:
> >
> > Mouse 1 1 A Menu WindowOps Delete
> >
> > with:
> >
> > Mouse 1 1 A Schedule 0 Menu WindowOps Delete
>
> Thank you.
> But there are some problems with this.
> The menu doesn't appear until the mouse button is released and when

When a menu is activated, no buttons may be pressed/depressed.
So a menu button should be depressed either before a menu started or
after it is closed.

> selecting an entry in the menu it's operation are not directly applied to
> the window in question, instead the pointer changes to a crosshair to
> select a window for the operation >
> (This is using 2.5.1)

I would suggest:

  Mouse 1 1 A Schedule 0 WindowId $w Menu WindowOps Delete

but this only makes Delete work, not a menu.
I think you can't run an arbitrary menu in a window context.

So currently what you want seems impossible to me. The behaviour where the
menu button is pressed on a menu popup is not bad, you may get used to it.
Also some people may like Popup instead of Menu (don't add Delete here):

  Mouse 1 1 A Popup WindowOps

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Mon May 20 2002 - 16:44:23 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST