Subject: changes in [Bb]indings.c

From: Dominik Vogt <[email-masked]>
Date: Wed, 4 Oct 2000 19:32:08 +0200

Olivier,

I am not quite sure what your changes intend to do, but I suspect
the fix for the FMR is a bit counter productive.  Bindings.c was
meant to be a generic file that can also be used by modules, but
now it seems to be hand modified for use by the main module
exclusively. I had a look myself yesterday, and I think the FMR
can be fixed by putting in a "break;" in the loop with the calls
to activate_binding() and RemoveBinding().

Can you please explain what your changes do?

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Olivier Chapuis <[email-masked]>
Date: Wed, 04 Oct 2000 19:48:31 +0200

> Can you please explain what your changes do?

Hello,

The difference in libs/Bindings is that now RemoveBinding
return some informations: a part of the removed binding and  
NULL if no bindings are removed. I do not see why this is 
counter productive for a (hypothetical) module that use the
Bindings.c library: the module get some informations (to 
grab/ungrab since the removed binding has disappear). We
may even want to return the complete removed bindings and
fvwm2 (bindings.c) is ready for that.

Why I do that? In the beginning I think like you: just
put a break in the original code. But, MatchBinding
does not say that a bindings will be removed by 
RemoveBinding: it may happen that MatchBinding answer
yes, but RemoveBinding remove no bindings (it is not
clear that this is a bug, it depends on your point
of view ...). Since the main module (fvwm2) needs to know
if the binding had been removed and need informations
on these bindings I've asked RemoveBinding to do the
job (again this may be useful for a poor module).
Moreover, we go through all the bindings only one
time and not two times. I've mad other minor modification,
so that activate_binding is not call when this is not needed
and also prevent an other loop on all the bindings
if (is_binding_removed) { ... }. So before, FVWM
(the metamodule) go through the bindings 3 times and
now only one or two times (two times if this is really 
needed).

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 4 Oct 2000 22:05:37 +0200

> fvwm2 (bindings.c) is ready for that.

Hm, originally I thought RemoveBinding() would remove multiple
matching bindings.  In this case the function might have removed
a binding that came later in the list and thus the loop in
bindings.c would have accessed an already deleted binding (hence
the FMR).  But this is not the case.  I guess the problem is
that the loop calls MatchBinding() to determine if a binding
has to be removed, but RemoveBinding() has a different notion
of the binding to remove.  It may delete a different one than
was originally intended.  If this happens to be the binding
after the one we intended to delete, the loop will proceed to
the deleted memory.

I said 'counter productive' because I thought RemoveBinding()
removed multiple bindings but returned only one of them.

I will think again about this problem.  There should probably
be two functions DestroyBinding() and a variant of
RemoveBinding() that simply looks for the binding structure in
the list instead of comparing binding types.

Bye

Dominik ^_^  ^_^