Hi, there exists a regression in awesome 3.5 (see [1] and maybe [2]): It’s not possible to use sloppy focus to exactly define which window should have the input focus. On fast mouse moves the wrong window is getting the focus. I tried to eliminate the problem and I even found a working solution (at least for me it’s working).
It seems to me, that awesome is handling all the focus itself but then there is the focusin-event listener. Probably awesome is switching the focus very fast (because of the sloppy focus and the fast moves). Now xcb fires focusin-events for each of the focus-switches and calls the function client_update_focus(c) where c is the window xcb sends in the event. But this must be the wrong window, because after the mouse move the correct window has the focus and after that there is the focusin-event for the wrong window. So awesome unfocuses the correctly focused window and gives the focus via the client_update_focus(…)-call to the wrong one. When I completely disable the focusin-event handler, everything works as I expect. So far I noticed also no other flaws since using my patched version of awesome. Probably my patch is not ok, but maybe there is someone who can point me in the right direction? There must be something wrong with the ordering of the events or maybe awesome triggers xcb events which it is receiving afterwards at the wrong time? The patch for discussion is in a follow-up. Best regards, Stefan Haller [1] http://thread.gmane.org/gmane.comp.window-managers.awesome/9692 [2] https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1084 -- To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
