[xmonad] Re: Patch: fix focus when user is moving the mouse

[Justin Bogner]

Spencer Janssen wrote:
> On Wed, Apr 09, 2008 at 02:13:39PM -0500, Klaus Weidner wrote:
>> Hello,
>>
>> the attached patch fixes an issue that had been bugging me - in
>> focus-follows-mouse mode, the input focus sometimes lagged behind the
>> mouse pointer, and as a result I was closing or typing into the wrong
>> window.
>>
>> Let me know in case there's a better way to approach this, I'm still new
>> to haskell and xmonad.
>>
>> I'll send a related patch to the UpdatePointer contrib module separately.
>>
>> -Klaus
>>
>> Remember if focus changes were caused by mouse actions or by key commands.
>>  
>>  If the user used the mouse to change window focus (moving into or clicking on a
>>  window), this should be handled differently than focus changes due to keyboard
>>  commands. Specifically, it's inappropriate to discard window enter/leave events
>>  while the mouse is moving. This fixes the bug where a fast mouse motion across
>>  multiple windows resulted in the wrong window keeping focus.
>>  
>>  It's also helpful information for contrib modules such as UpdatePointer - it's
>>  supposed to move the mouse pointer only in response to keyboard actions, not if
>>  the user was moving the mouse.
> 
> First, a minor nitpick: if you want this patch to be applied, please change all
> identifiers to camelCase for consistency with the rest of xmonad.
> 
> I foresee some problems with this patch.  Consider the following sequence of
> events, starting from an empty workspace in the Tall layout:
> 
>  - increment nmaster to three
>  - create three xterms
>  - focus the second window with the mouse.  At this time mouse_focus
>    will be set to True
>  - position the mouse such that it occupies the upper half of the second window
>  - close the second window without using an xmonad keybinding (typing 'exit' in
>    an xterm will suffice)
>  - the windows will shuffle about, and xmonad will set focus to the last window
>    as usual.  Also, the first window will now be under the mouse pointer, and
>    an entry event will be generated.
> 
> In the old system, this entry event is removed and all is well.  With your
> proposed changes the entry event will not be removed, and focus will be changed
> to the first window -- not good!
> 
> 
> Cheers,
> Spencer Janssen

Why isn't this good? the focus staying under the mouse seems more sane 
than it going to an arbitrary window (the last).
_____
Justin Bogner