Subject: Re: CVS domivogt: * Actions can be bound to windows swallowed in FvwmButtons.

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Jan 2002 21:44:44 +0100

On Wed, Dec 19, 2001 at 03:16:07PM +0100, Olivier Chapuis wrote:
> On Wed, Dec 19, 2001 at 10:50:48AM +0100, Dominik Vogt wrote:
> > On Fri, Dec 14, 2001 at 11:57:17AM +0100, fvwm-workers wrote:
> > > On Thu, Dec 13, 2001 at 09:07:51PM +0100, Olivier Chapuis wrote:
> > > > On Thu, Dec 13, 2001 at 03:23:37AM -0600, FVWM CVS wrote:
> > > > > CVSROOT:	/home/cvs/fvwm
> > > > > Module name:	fvwm
> > > > > Changes by:	domivogt	01/12/13 03:23:37
> > > > > 
> > > > > Modified files:
> > > > > 	.              : NEWS 
> > > > > 	modules        : ChangeLog 
> > > > > 	modules/FvwmButtons: FvwmButtons.c 
> > > > > 
> > > > > Log message:
> > > > > * Actions can be bound to windows swallowed in FvwmButtons.
> > > > 
> > > > Hello,
> > > > It seems to me that there a problem here. Say that
> > > > we have a *shaped* application that you sallow in a
> > > > FvwmButtons and that app needs buttons click (as a
> > > > mini cd player). With the old code, as the application
> > > > is shaped you can define FvwmButtons Actions that are
> > > > executed when you click on the FvwmButtons button
> > > > that swallow the app but "out of the mask" and the
> > > > click on the swallowed app is still passed to the
> > > > app.
> > > > With the new code this does not work any more, as
> > > > the mouse buttons are grabbed, a mouse click never
> > > > goes to the swallowed app and the FvwmButtons Actions
> > > > is always executed.
> > > > I see two solutions:
> > > > 1) do not grab the mouse buttons in the case of
> > > > the swallowed app is shaped.
> > > > 2) add a new action command: GrabedAction which do
> > > > what the new code do and keep the old code for the
> > > > Action.
> > > 
> > > 3) Pass the click to the application despite of the click.
> > 
> > Is that a real or a theoretical problem?  I can't find any shaped
> > application I might want to swallow in FvwmButtons that does
> > something with mouse clicks.
> > 
> 
> It is a real problem: I discover this because I used such app
> (with action defined when I click on the shapped part):
> There are a lot of Window Maker and AfterStep applet which needs
> mouse click and which have shape.
> 
> I do not think it is difficult to add a GrabedAction command.
> I can add it if you want.

The new behaviour is now the default, but you can disable it with
the new option "ActionIgnoresClientWindow", e.g.

  *FvwmButtons(Action beep, ActionIgnoresClientWindow, \
     Swallow xload "exec xload")

Is that good enough?  I think breaking the use of that
undocumented old behaviour for shaped windows is a rare occurance,
but it helps a lot for new users that try to get the new
functionality.  Can we agree about this approach?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 16 Jan 2002 20:52:07 +0000

> functionality.  Can we agree about this approach?

Should not this be a property of action rather than a global option?
I.e.:

  *FvwmButtons: (Swallow something "exec xterm -name something", \
    Action (OutsideClientWindow) Exec xload, \
    Action (Mouse 2, OutsideClientWindow) Exec xclock, \
    Action (Mouse 3) Beep, \
  )

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Jan 2002 22:31:51 +0100

> Should not this be a property of action rather than a global option?

Maybe, but there's no clean way to specify this.  If you use

  ... Action "beep", Action (Mouse 1, ActionIgnoresClientWindow) "echo hello" ...

the ActionIgnoresClientWindow of the button 1 binding will be
ignored because the global action demands it.  I thought this was
not important enough to allow the distinction.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 17 Jan 2002 13:47:54 +0100

> functionality.  Can we agree about this approach?

Yes for me, Olivier