TWM / VTWM and keyboard binding

[iWantTo KeepAnon]

I have bound :
"Tab" = m4 : all : f.circleup
"Tab" = m4|s : all : f.circledown

where m4 => the windows key (on my keyboard at least). This is
supposed to work like Alt+Tab and Alt+Shift+Tab on a windoze system.

My problem is that an application gets the keystrokes before the WM
does (the windows _are_ managed). So I have to move my mouse to the
title bar or to the root window before this binding works. Doesn't
this contradict the "all" context ... all = *window* | title | icon |
root | frame | iconmgr.

Is there a way to have TWM or VTWM grab the keystoke so that, for
instance, XEmacs and Opera never sees it? Right now XEmacs says
"S-TAB not defined" and Opera just ignores me (fyi "S-TAB" is
Supermeta-Tab which is equivalent to "m4|s" in TWM speak).

Thx for your help ...

[Jack McCue]

Post by iWantTo KeepAnon
"Tab" = m4 : all : f.circleup
"Tab" = m4|s : all : f.circledown

According the the vtwm man page I have '4' is not
defined, but it may not be documented in the page.
Maybe try different combinations of spaces, something
like m4 l s. xev can be used to get key codes,
I do not have a "windows key" so I can't play with
it in vtwm.

Post by iWantTo KeepAnon
where m4 => the windows key (on my keyboard at least). This is
supposed to work like Alt+Tab and Alt+Shift+Tab on a windoze system.
My problem is that an application gets the keystrokes before the WM
does (the windows _are_ managed). So I have to move my mouse to the
title bar or to the root window before this binding works. Doesn't
this contradict the "all" context ... all = *window* | title | icon |
root | frame | iconmgr.

I agree, if the key is defined in .vtwmrc/.twmrc
correctly the app will never see it. Are you using
xmodmap ? Maybe there is something going on there ?

Post by iWantTo KeepAnon
Is there a way to have TWM or VTWM grab the keystoke so that, for
instance, XEmacs and Opera never sees it? Right now XEmacs says
"S-TAB not defined" and Opera just ignores me (fyi "S-TAB" is
Supermeta-Tab which is equivalent to "m4|s" in TWM speak).
Thx for your help ...

Wish I could have helped more, Hopefully I gave you
some ideas anyway :)
Jack

[D J Hawkey Jr]

Post by Jack McCue

Post by iWantTo KeepAnon
"Tab" = m4 : all : f.circleup
"Tab" = m4|s : all : f.circledown

According the the vtwm man page I have '4' is not
defined, but it may not be documented in the page.
Maybe try different combinations of spaces, something
like m4 l s. xev can be used to get key codes,
I do not have a "windows key" so I can't play with
it in vtwm.

From the VTWM 5.4.6 man page:

The modlist is any combination of the modifier names
shift, control, lock, meta, mod1, mod2, mod3, mod4, or
mod5 (which may be abbreviated as s, c, l, m, m1, m2, m3,
m4, m5, respectively) separated by a vertical bar (|).

Post by Jack McCue

Post by iWantTo KeepAnon
where m4 => the windows key (on my keyboard at least). This is
supposed to work like Alt+Tab and Alt+Shift+Tab on a windoze system.

I don't know that XF86 maps the Windoze(tm) key to any of these
"state" modifiers. Like Jack, I don't use a Windoze(tm) keyboard
(I prefer the old, 35-lb., IBM 101-keyboards), so I don't know.

Grepping /usr/X11R6/include/X11/keysymdef.h for "window" turns up
nothing.

Post by Jack McCue

Post by iWantTo KeepAnon
My problem is that an application gets the keystrokes before the WM
does (the windows _are_ managed). So I have to move my mouse to the
title bar or to the root window before this binding works. Doesn't
this contradict the "all" context ... all = *window* | title | icon |
root | frame | iconmgr.

I use the "all" context keyword, and it does indeed trap the mapped
keystrokes, even when the pointer is in the application per se.

Post by Jack McCue

Post by iWantTo KeepAnon
Is there a way to have TWM or VTWM grab the keystoke so that, for
instance, XEmacs and Opera never sees it? Right now XEmacs says
"S-TAB not defined" and Opera just ignores me (fyi "S-TAB" is
Supermeta-Tab which is equivalent to "m4|s" in TWM speak).

You're doing it correctly. As Jack asked, has xmodmap changed things
on you? Are you certain of the above assertion? What does xev show for
that Windoze(tm) key?

As a last resort, I'm sure you can find other key(s) for your binding,
no?

Sorry I can't help much more than Jack,
Dave
(current VTWM maintainer)

[Jack McCue]

D J Hawkey Jr <***@visi.com> wrote:

<snip OP Windows Key map Issue>

Post by D J Hawkey Jr
The modlist is any combination of the modifier names
shift, control, lock, meta, mod1, mod2, mod3, mod4, or
mod5 (which may be abbreviated as s, c, l, m, m1, m2, m3,
m4, m5, respectively) separated by a vertical bar (|).

read that in the man page but it did not sink in, :(
mod4 = m4, thanks Dave!

<snip>

Post by D J Hawkey Jr
Dave
(current VTWM maintainer)

great work on keeping VTWM going
Jack

[iWantTo KeepAnon]

Post by D J Hawkey Jr
I don't know that XF86 maps the Windoze(tm) key to any of these
"state" modifiers. Like Jack, I don't use a Windoze(tm) keyboard
(I prefer the old, 35-lb., IBM 101-keyboards), so I don't know.

I do too. You could just about dump one in a bath tub to clean it
and it'd still work.

The "windoze key+Tab" works over the root window and titles, and
xmodmap shows mod4 = windoze key.

Post by D J Hawkey Jr
I use the "all" context keyword, and it does indeed trap the mapped
keystrokes, even when the pointer is in the application per se.

...

Post by D J Hawkey Jr
As a last resort, I'm sure you can find other key(s) for your binding,
no?

Actually, I already have Alt-Tab doing this. But it fails when the cursor
is in an application window too. The application takes the key and either
ignores it or if it recognizes it, just does some app. specific behaviour.

What I really posted for was to make certain there wasn't .[v]twmrc setting
that said "give the app first look at keys" (or something similar). If
that were the case, I'd hoped to get an RTFM. But it doesn't sound that
easy.

Post by D J Hawkey Jr
Sorry I can't help much more than Jack,
Dave
(current VTWM maintainer)

Thanks for all the feedback.

[D J Hawkey Jr]

Post by iWantTo KeepAnon
The "windoze key+Tab" works over the root window and titles, and
xmodmap shows mod4 = windoze key.

OK, so far, so good.

Post by iWantTo KeepAnon

Post by D J Hawkey Jr
I use the "all" context keyword, and it does indeed trap the mapped
keystrokes, even when the pointer is in the application per se.

...

Post by D J Hawkey Jr
As a last resort, I'm sure you can find other key(s) for your binding,
no?

Actually, I already have Alt-Tab doing this. But it fails when the cursor
is in an application window too. The application takes the key and either
ignores it or if it recognizes it, just does some app. specific behaviour.

Are we talking _any_ application, or just certain ones (and if so,
which ones)?

I'm thinking of KDE and GNOME apps that take it upon themselves to try
to enforce policies outside themselves, like stacking order, click-to-type
focus, etc..

Post by iWantTo KeepAnon
What I really posted for was to make certain there wasn't .[v]twmrc setting
that said "give the app first look at keys" (or something similar). If
that were the case, I'd hoped to get an RTFM. But it doesn't sound that
easy.

Not that I recall, no. I could see where a click-to-type focus policy
(set up in VTWM, not in an app) _might_ influence things, but this is
just speculation.

One last thing I might suggest is that your VTWM resource file be set up
with the following "sections" in this order:

1) Boolean variables
2) Parametered variables
3) Functions and bindings
4) Lists
5) Menus

I have seen instances where "sections" in orders other than this have
produced unexpected behavior (some resources do depend on others).

Dave

[iWantTo KeepAnon]

Post by D J Hawkey Jr

Post by iWantTo KeepAnon
The "windoze key+Tab" works over the root window and titles, and
xmodmap shows mod4 = windoze key.

OK, so far, so good.

I noticed something ... then I found my oversight. Let me 'splain.

I noticed that when the num lock key was off, all my bindings started
working just fine. When the num lock key was on, the applications started
getting the key strokes.

My oversight: I thought that the bindings were for keys "actively" pressed
(like alt and tab). But the WM apparantly looks at all of the statuses of
the mod keys to pick its binding. So I added an identical set of bindings
with "m2" or'd in and now everything works as expected when the num lock
is on. Supposedly, I'd need to add another set for caps, scroll, etc...?

Sorry to take up your debugging time for such a green mistake. I have read
a lot of .rc files and never noticed anyone allowing for duplicate bindings
based on the num lock being on or off. Is this common?

Thanks again to all who responded ...

[D J Hawkey Jr]

Post by iWantTo KeepAnon
I noticed something ... then I found my oversight. Let me 'splain.
I noticed that when the num lock key was off, all my bindings started
working just fine. When the num lock key was on, the applications started
getting the key strokes.
My oversight: I thought that the bindings were for keys "actively" pressed
(like alt and tab). But the WM apparantly looks at all of the statuses of
the mod keys to pick its binding. So I added an identical set of bindings
with "m2" or'd in and now everything works as expected when the num lock
is on. Supposedly, I'd need to add another set for caps, scroll, etc...?

I'll be darned.

As I rarely toggle NumLock on, I never noticed this, but what you
describe is true here, too (VTWM 5.4.7, XF86 4.2). Same goes for
CapsLock and ScrollLock, too.

Post by iWantTo KeepAnon
Sorry to take up your debugging time for such a green mistake. I have read
a lot of .rc files and never noticed anyone allowing for duplicate bindings
based on the num lock being on or off. Is this common?

A "green mistake"? I've been running X for a long time now, and I
never noticed this - I never tried.

Dunno if this is common or not. You're the first to report this that
I've seen, and I haven't seen additional bindings for these "state"
keys in any resource file that has been sent to me.

I guess I should note this behavior to the man page, eh?

-------

Question for the group: Should add these bindings to the default
bindings? Is this behavior consistant on non-Intel platforms or
on non-XFree86 servers?

-------

Dave

[Dan Espen]

Post by D J Hawkey Jr

Post by iWantTo KeepAnon
I noticed that when the num lock key was off, all my bindings started
working just fine.

Dunno if this is common or not.

Common?
See the Fvwm FAQ, question 0.1 and then 5.5.
http://www.fvwm.org/documentation/faq/

Just read it. It may be The Most Asked Question for the FVWM
maintainers, but I've never asked it, and nobody's ever asked it of me.

(You have to click thru the first page)

Such silliness. Like the patent holders/applicants or the USPTO are
going to change their practices because everyone has/will put up a
"protest" click-through page.

As I understand it, its aimed at the EPO (European Patent Office).
I doubt the EPO cares about Fvwm, but no business or agency likes
negative publicity.

Thanks for the pointer. I s'pose I'll have to do something about this
in VTWM, too.

Even though the FAQ has been that way for years,
the question still gets asked.
Sometimes, its a vague "Fvwm works for a while, then stops".

[D J Hawkey Jr]

Post by D J Hawkey Jr
As I rarely toggle NumLock on, I never noticed this, but what you
describe is true here, too (VTWM 5.4.7, XF86 4.2). Same goes for
CapsLock and ScrollLock, too.

Something else occured to me shortly after my last post ... why did the
keys work over the root window? I do not have any bindings that mention
the numlock key and the root window. In theory, the bindings as in my
.[v]twmrc should not have worked at all!?

It has to do with the contexts that VTWM will grab keys in (XGrabKey(3)).
The root window has no grabs placed on it.

And since I found this "feature", I can toggle my numlock off and on and
suddenly the left click "Twm" menu fails to drop down (I get a beep
instead). I would need to create a "button1 : numlock" binding for that
to work.
For now, I am keeping my numlock off and everything works "as described".

All fixed up now. From the CHANGELOG file:

September 10, 2003
[add_window.c] [gram.y] [menus.c] [parse.c] [twm.c] [add_window.h]
[screen.h] [twm.h]
Added code to ignore "shift states" for bindings.

Added the following variable:
IgnoreModifiers k

Fuller documentation in the man page, of course.

Dave

[D J Hawkey Jr]