FVWM: Application binding changes patch

From: Ted Faber <faber_at_ISI.EDU>
Date: Fri, 16 Jan 1998 17:32:32 -0800

Yes, I know I said I didn't have time to patch this, but it
exasperated me to the point of fixing it.


The problem:

Mouse 1 A C Iconify

followed by a later

Mouse 1 A C -

doesn't pass events like Mouse 1 C through to application windows,
although windows created with the second binding in effect do see such
events. This seems inconsistent with removing the binding.

Why do I care:

I don't use titlebars, and I want to be able to turn off my iconify
binding (above) to use application features.

The cause:

Whenever a new window is created, the bindings list is used to set
passive grabs in the various application windows. On the event, fvwm
scans the bindings list and executes the bound function.

However, when a binding is cancelled, the binding is only removed from
the list, the grabs are unaltered. This means that keys/buttons
formerly bound (like the mouse button above) are still grabbed, but no
function is executed. Unfortunately the application never sees the event.

Because the majority of people bind keys and buttons in titlebars and
root contexts and rarely change them, this hasn't been a problem for
them - the root window wouldn't act on the keypress if fvwm didn't.

The solution:

I added code to the part of remove_binding() that removes the binding
from the list. The new code checks to see if the removed binding was
an application context or all context binding, and if so it removes
all the grabs on application windows and reinstates relevent ones
using GrabButtons or GrabKeys as appropriate after the binding list
has been changed. (Note this is just removing and establishing Grabs,
nothing is redrawn.)

It's linear in the number of windows, but it's also easier than
parsing the whole bindings list to see which bindings would have to be in
effect, too. I think these changes are infrequent enough, and there
are few enough windows that this brute force algorithm is sure to be
right, and not too expensive.

Let me know what you think. Since I'm posting patches, I'm now
subscribed to the list.

The patch:

Relative to fvwm-2.0.46/fvwm

*** bindings.c Fri Jan 16 17:06:06 1998
--- bindings.c.orig Wed Jun 19 20:02:12 1996
***************
*** 72,78 ****
  {
    Binding *temp=Scr.AllBindings, *temp2, *prev=NULL;
    KeyCode keycode;
- FvwmWindow *w;
  
    if (!mouse_binding)
      keycode=XKeysymToKeycode(dpy,keysym);
--- 72,77 ----
***************
*** 97,119 ****
          }
          free(temp);
          temp=NULL;
-
- /* if we change an application or an all context binding,
- adjust the grabs on all application windows so the
- applications can see the events */
-
- if ( contexts == C_ALL || contexts == C_WINDOW ) {
- for ( w = Scr.FvwmRoot.next; w != NULL ; w = w->next) {
- if (mouse_binding) {
- XUngrabButton(dpy,AnyButton,AnyModifier,w->w);
- GrabButtons(w);
- }
- else {
- XUngrabKey(dpy,AnyKey,AnyModifier,w->w);
- GrabKeys(w);
- }
- }
- }
        }
      }
      if (temp)
--- 96,101 ----


--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Jan 16 1998 - 19:32:53 GMT

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:38:01 BST