Subject: Getting KeyRelease Events?

From: Sean Reifschneider <[email-masked]>
Date: Wed, 9 Sep 1998 04:13:54 -0600

Greetings.  I decided to bite the bullet and try to finally make a
change I've been wanting for years.  I want to implement something
similar to the MS Windows "Cool Switching".  Basicly, the current window
is always the top of the list of windows to cycle through, and holding
down "Alt" while pressing tab moves you back another window.  When the
Alt key is released, the selected window is moved to the top.

This implements an LRU list of windows, making switching between two
windows simple and intuitive (no having to remember if the window you
want is in front of or behind your current window).

However, in a few hours of digging in the code tonight, I couldn't find
any way to grab the KeyRelease events for the modifiers.  It's easy enough
to get the actual Alt-Tab event, but getting the Alt-release event was
only possible when the focus was not set to any application windows.

I would think that if the code gets the actual button events such as
Tab with modifier, it would be easy enough to get the Alt-released event.
Any hints?

I figured when I got the "CoolPrev" event the first time, I'd check to see
if any modifiers were pressed.  If they weren't, it would just act like a
"Prev".  If there was a modifier, the "cool mode" would be enabled, and
release events would be watched.  Once *ALL* the modifier keys are released,
the window order would be reorganized.  This would allow, for example,
mapping Alt-Tab to CoolPrev, and Alt-Shift-Tab to Next, giving you two
way traversal of the stack, without prematurely raising the window (say,
when "shift" was released).

Any comments would be appreciated.  MS Windows has always been rather easily
manouvered with only the keyboard.  While I'm not a big fan of MS Windows,
CoolSwitching is done right.

Thanks,
Sean
-- 
I would rather suffer defeat than have cause to be ashamed of victory.
                -- Quintus Curtius
Sean Reifschneider, Inimitably Superfluous <[email-masked]>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Tim Phipps <[email-masked]>
Date: Wed, 09 Sep 1998 14:34:36 +0100

> Alt key is released, the selected window is moved to the top.

It sounds like there are two separate things you are trying to do here:
1) Explicit control of the focus order
2) Fancy keyboard interface to 1)

2) could be very hard given that fvwm ignores releases and does things
on presses only.  To get the behaviour you want would require fvwm to
treat key presses like button presses i.e. have an "I" field in the key
binding so that it will know if a key click/press/raise action is
required.  This would mean changing the fvwmrc syntax in a way that
would break all existing ones.

1) is almost doable with 2.0.47d but it needs a slight alteration to the
new menu code.  Try this

Key Tab A M WindowList CurrentDesk, NoGeometry
DestroyFunc WindowListFunc
AddToFunc WindowListFunc "I" WindowId $0 FlipFocus
+                        "I" WindowId $0 WarpToWindow 5p 5p

The CurrentDesk arg is necessary as WindowList sorts by desk number

This works as long as the cursor is in the root window when you hit
Alt-Tab or if you use clicktofocus.

Things better than Windows:
*) you type a number to go straight to the window you want
*) all window titles are displayed so you don't have to search
   when you have 6 netscapes
*) it pops up under the cursor which you can use to select as well
*) you can use the arrow keys to go up and down
*) if you switch geometry on the window state is displayed

Things worse than windows:
*) it defaults to the current window not number 2
*) you have to hit a key to get out rather than just let go (big deal)
*) it doesn't look like windows (another big deal)

Surprises:
Next, Prev and Focus don't change the windowlist so if you use them you
don't get the current window at the top of the list.  I would guess that
if you use this method you might not use Next/Prev much.  I don't think
we should change these commands either.

If you want a really fast way of switching try 
Key KP_Enter A N WindowList CurrentDesk, NoGeometry

Your hand is right over the numeric keys so simple Alt-tab behaviour is
just KP_Enter, KP_2 i.e. two keys (closer than alt & tab too)

Buglet/missing feature:
The new menu code returns the pointer back from whence it came when a
menu disappears.  This is the wrong thing to do in this case. What
happens is that the new window is focused to and then the mouse is moved
back so if you have mouse/sloppy focus you don't get anywhere.  The menu
code should take an extra arg that specifies whether to return the
cursor or not and the WindowList command should use it.  I haven't
looked at the code but I would guess that this is fairly easy to do
given that menus aren't called from too many places.

It might also be an idea to allow geometry specs for menus so you can
pop them up where you like e.g. the middle of the screen, we could then
do an Alt-Space menu like Windows i.e. pops up in the top left corner of
the current window and a Start menu like windows.

Anyone care to have a go at this?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 09 Sep 1998 16:02:50 +0200

> the current window and a Start menu like windows.

I have done something like this with my version of 2.0.46. With
the
patches I made you can place a menu relative to the item that
popped
up the menu (e.g. below the mouse pointer or above a button). The
syntax of the 'Menu' and 'Popup' commands has to be changed
substantially
in order to allow this. I think enhancing this to handle absolute
placement wouldn't be too hard.

I have another suggestion for menus. What about some kind of
'panels'
which work like menus but just stay on the desktop like any other
window until you select an entry. Unlike normal menus such a
'panel'
would not force you to select something immediately. You could
just continue working and leave the panel open (just like the
CDE/VUE subpanels).

> Anyone care to have a go at this?

I would do it if you can give me a hint how I can join the
official
development team (or should I just make a patch? This would be
for 2.0.46 however).

-- 
------------------------------------------------------------------
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Tim Phipps <[email-masked]>
Date: Wed, 09 Sep 1998 16:04:58 +0100

> development team (or should I just make a patch? This would be

Just send a patch to the fvwm-workers list, that's what I do (or did a
long time ago when I had time).  But don't do it for 2.0.46 since the
menu code has changed an awful lot and it won't be going back.  2.0.47d
has been the latest for several weeks now and is available from
ftp://fozzie.cs.arizona.edu/pub/fvwm

There have been a few patches since but I don't think they are to do
with the menu code.

I've a couple of thoughts on the syntax, it's for Popup only since Menu
is intended for mouse button presses and they work OK. Popup is the
command to get menus from keys or events and it doesn't have the
optional double-click-action parsing complexity of Menu

Popup menu-name [x y] 

where x & y are a superset of the syntax of the move command i.e.
+10, +10p, -10, -10p, w+10, w+10p, w-10, w-10p
where numbers are percents or pixels offsets from the root window or
current window edges and 
c+10, c+10p, c-10, c-10p, cw+10, cw+10p, cw-10, cw-10p
position the menu centre at the root or current window centre with
offsets (maybe this is overkill and just a flag to centre on screen will
do).

w+0 w+0 would give a menu in the top left corner just like Alt-Space
does in Windows.
+0 -0 would give the bottom left of the screen
c+0 c+0 would splat a menu in the middle of the screen

This scheme will not allow menu to be positioned outside the edges of
windows.  I've never seen anything like that but I could imagine it
being nice for some e.g. pop a menu that's aligned with the left edge of
a window but not overlapping.  The syntax would need to be extended to
allow left/right/top/bottom edged of windows to be specified rather than
just inferring from the sign of the offset. Besides that, what do you do
if there isn't room? Move the window and then pop the menu?

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 09 Sep 1998 17:16:20 +0100

Tim Phipps just spouted some ribbish without checking:
> Your hand is right over the number keys so simple Alt-tab behaviour is

This doesn't work, I can't get the WindowList Menu to use the keypad
keys, just the ones above QWERTY.  Is this a misiing feature?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 11 Sep 1998 10:13:43 +0200

> c+0 c+0 would splat a menu in the middle of the screen

I was thinking about a more general way to do that. Menu und
Popup (and perhaps WinList) would have the following parameters:

 Popup Name [ [<context>] x y ]
 Menu  Name [ [<context>] x y ] DoubleClickAction

x and y have the syntax you described (except that there is no
'w', this is part of <context>). The <context> Argument is
optional and specifies the reference rectangle of the x/y
values. It can have the following values:

 Value       Reference rectangle:
----------------------------------------------------------------------
 context     the x/y/w/h values of the spawning window/menu
 root        the screen
 mouse       a 1x1 rectangle at the mouse position
 <geometry>  a rectangle specified in XGeometry style

The plus of this syntax is that you can place a menu relative
to a button of FvwmButtons (with some enhancement of the
Buttons syntax).
 
> a window but not overlapping.

If you have seen CDE or VUE, you *have* seen it. It's
exactly the way the subpanels in the front panel are
positioned: Just above a button and centered with its
x coordinates.

> The syntax would need to be extended to
> just inferring from the sign of the offset.

No, not with the above suggestions: If you want the bottom left
corner of a menu to touch the upper right corner of the 
spawning menu you can write:

  Menu foo context +100 -100

Context means the menu is positioned relative to the window,
just right of it's right border (+100) and above it's upper
border (-100). So values over 100 or below -100 can save
you the effort of additional flags like 't', 'b', 'l' and
'r'.

> Besides that, what do you do

Good question. With the patch I made for 2.0.46 the x/y
coordinates
are just moved into the screen if necessary, but this causes
some problems near the right border of the screen (overlappping
popups).

I am already working with the 2.0.47d source to implement
this, just give me some time.

Bye

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Fri, 11 Sep 1998 09:50:28 +0100

>  Value       Reference rectangle:

I think I'm being dim but I don't get how this specifies which part of a
menu is being positioned or is it always the top left? I thin it would
be nice to say "top left of menu in top left of window" or "centre of
window in centre of screen" or "top right of menu in top left of
window". It's 81 (3^4) possible combinations plus x,y signed offsets.
How do you get a root centred menu? How do you get a menu abutted to the
left side of a window if you don't know it's width? I like the context
bit but I don't think just x y is enough unless you start special casing
certain numbers like 0<=x<50:-"left edge", x=50:-"horizontally centred",
50<x<100:="right edge", 100<x:="left edge".

> > This scheme will not allow menu to be positioned outside the
> > edges of windows. 
> If you have seen CDE or VUE, you *have* seen it.

Duh! Sorry, VUE frontpanel = deeply repressed memory.

> this, just give me some time.

Go for it, patch away and I'll be a Guinea pig.

Cheers,
Tim.