On Tue, Sep 02, 2014 at 10:58:30PM +0100, Dominik Vogt wrote: > On Tue, Sep 02, 2014 at 04:19:33PM -0500, [email protected] wrote: > > Log message: > > Update passive grabs tracking modifiers > > > > In the case of GTK's link widget which doesn't handle passive grabs > > following FVWM's window bindings (which assumes the underlying > > application can handle a PointerReplay), update the grabs in this > > context by always ungrabbing the button and grabbing it for modifiers > > other than ALL_MODIFIERS. > > > > I've had this in testing for three years and recently dusted it off for a > > bug report I received for another application with this problem, called > > darktable. > > Can you please explain the problem in even more detail? Grabbing > is a crucial part of fvwm that I want to understand completely. > (A diff would also be nice for convenience; they're so difficult > to get from CVS.)
I'm so sorry, Dominik. I have no idea why I didn't see this reply sooner. The specifics of the changes can be found here: https://github.com/ThomasAdam/mvwm/commit/46213db4892ea00cfcd5fd421ac82b9a32c074b5 The problem (as I can see it) is that fvwm grabs everything. What I noticed with some recent GTK applications is that mouse bindings assigned in general to windows were interferring with them in that the application couldn't respond to certain things, such as clicking on links, etc. So when I looked into this, I tried to change fvwm to only grab the things it needed based on the modifiers in use, etc. But this clearly broke a few other things (which I don't use). Looking into this further still, it seems Compiz have a similar fix to my proposal above: http://git.compiz.org/compiz/core/commit/?id=cf2117be87040f5f19be6b688d481f7369b0f7b5 -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
