Subject: Re: FVWM: rdesktop and passing through control/alt keys

From: Dan Espen <[email-masked]>
Date: Mon, 02 Dec 2002 11:17:22 -0500

Tessa Lau <[email-masked]> writes:
> 
> I have a different but related problem: I use Lotus Notes under wine,
> and when I use Ctrl-Alt-arrow to switch desktops when wine is in
> focus, sometimes the Ctrl/Alt keypress _is_ sent to wine.  When I
> return to wine, it thinks that Ctrl or Alt was pressed but never
> released.
> 
> I suspect that this is wine's problem, but is there some workaround I
> can use in fvwm, to tell it not to pass those keystrokes to the window?

I can't test this since I'm not at work, Notes/Wine is way to slow for
remote use.

I was able to use C/A arrow with other programs under wine.

Are you letting Fvwm manage the windows?
In $HOME/.wine/config you should have this:

; Allow the window manager to manage created windows
"Managed" = "Y"

-- 
Dan Espen                           E-mail: [email-masked]
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Sam Kalet <[email-masked]>
Date: Mon, 2 Dec 2002 11:25:12 -0500 (EST)

I also have a similar situation - I am using Sun's SunPCI software with fvwm and keys such as F1 are consumed by the app when in focus and the fvwm binding is not invoked.  I can't seem to determine what the difference between this window and others are that causes this behavior.  With most other apps if an fvwm binding and application key overlap, the fvwm binding seems to have precedence (such as F-keys in acroread), but this is different.  Additionally, in certain states the SunPCI app does not have a use for F1, in these cases the fvwm binding is invoked.

I would expect the window manager to have the ability to tame these apps, but haven't come across a solution yet.  Does anyone have some insight into why apps seem to behave differently regarding precendence application-specific key bindings and fvwm key bindings?  Any thoughts on forcing precedence to window manager key bindings over application key bindings?

Thanks!

On Sat, 30 Nov 2002, Tessa Lau wrote:

> --Tessa

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 2 Dec 2002 17:31:18 +0100

> ; Allow the window manager to manage created windows

This should not happen anymore in fvwm-2.5.4 or later with key
bindings using the "A"ny context.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 2 Dec 2002 17:39:10 +0100

On Mon, Dec 02, 2002 at 11:25:12AM -0500, Sam Kalet wrote:

(please break the lines in your mail - a single 1000 character
line is nigh unreadable with many mail clients).

> I also have a similar situation - I am using Sun's SunPCI software
> with fvwm and keys such as F1 are consumed by the app when in
> focus and the fvwm binding is not invoked.  I can't seem to
> determine what the difference between this window and others are
> that causes this behavior.  With most other apps if an fvwm
> binding and application key overlap, the fvwm binding seems to
> have precedence (such as F-keys in acroread), but this is
> different.  Additionally, in certain states the SunPCI app does
> not have a use for F1, in these cases the fvwm binding is invoked.
> 
> I would expect the window manager to have the ability to tame
> these apps, but haven't come across a solution yet.  Does anyone
> have some insight into why apps seem to behave differently
> regarding precendence application-specific key bindings and fvwm
> key bindings?  Any thoughts on forcing precedence to window
> manager key bindings over application key bindings?

It is a matter of which application grabs which key strokes on
which window.  The grab on the highest level window wins the grab.
If applications try to grab on the same window, the first one to
make the request wins.  Normally, applications do not need to grab
keys as they already receive keyboard input in the usual way, but
some super sly programmers seem to believe they do the user a
favour by grabbing certain keys on their windows.  Since the
application is always faster to grab them, the window manager
can not establish the grab on the client window.  To override
that, the WM has to grab the key on a higher level window.

fvwm-2.5.4 and later already have a patch to deal with such
applications.  Bindings with the "A"ny context are grabbed on the
root window:

  Key F1 A n echo got it

It does not work with other contexts, though.

Bye

Dominik ^_^  ^_^