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

On Wed, Apr 09, 2008 at 04:55:35PM -0500, Spencer Janssen wrote:

On Wed, Apr 09, 2008 at 03:45:51PM -0600, Justin Bogner wrote:

...

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

The choice isn't arbitrary, focus always goes to the next window in stack order. The idea behind the current system is that the user can totally ignore the position of the mouse when managing windows -- and I'd rather avoid any change that breaks this property.

I agree with Spencer here. I'm still not convinced that our current approach is better than maintaining a focus stack, but it's definitely better for the behavior when you close a window to no be dependent on where the mouse happens to be, and how you happen to have shifted focus to the current window. -- David Roundy Department of Physics Oregon State University

I've attached an updated patch with the flag camelCased and additional logic to ensure that the behavior stays mouse position independent when adding or removing windows. Please let me know if there's a better way to do this. I'm not sure if there'd be a good place to clear the flag on relevant events without needing to put code into the individual handlers. -Klaus On Wed, Apr 09, 2008 at 06:25:22PM -0500, Klaus Weidner wrote:

Spencer Janssen wrote:

...

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.

Sorry about that, I'll fix it. Is it okay to use "darcs unrecord" and redo the patch, or should it be incremental?

...

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!

This wouldn't bother me personally, but I understand the rationale that you had explained to Justin.

Would it be sufficient to simply clear the mouseFocused flag in the event handlers for MapRequest/DestroyWindow/Unmap, so that any changes to the window list that are outside of the control of xmonad preserve the original behavior?

-Klaus _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

On Wed, Apr 09, 2008 at 06:25:22PM -0500, Klaus Weidner wrote:

Spencer Janssen wrote:

...

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.

Sorry about that, I'll fix it. Is it okay to use "darcs unrecord" and redo the patch, or should it be incremental?

darcs amend-record is easier... -- David Roundy Department of Physics Oregon State University