On Sun, May 10, 2009 at 10:10:43AM +0200, Julien Danjou wrote: > Retry without keynav? > It's possible keynav is generating an event that makes awesome thinks > the pointer is entering the window. > Or try disabling sloppy focus.
Somehow, it never came to my mind that it might have something to do with an external app, since it did work before and the only thing I changed was awesome. You are right, another program interferes. It's not keynav, but unclutter, which hides the mouse pointer after some timeout. I guess I have to switch back to my own solution. > > I'm using Opera as my main webbrowser. Opera uses various transient > > windows to query information. So let's say I type the shortcut to open > > the "go to page" dialog. Sometimes, in fact very often, the focus > > stays on the main window, while it should be in the dialog window. > > This also happens with other dialog windows, like the "save to file" > > popup. > > I think that might be the same issue as above. > If the window opens and your mouse is on the main window, that's > possible something else sends a event that makes awesome think the mouse > has moved. Killing unclutter made it reproducable and traceable to the extra no_overlap/no_offscreen manage hook. If I put it in the default manage hook, right before the client.focus = c line, the issue is gone. (I wonder why I didn't do this in the first place. Maybe the config upgrade procedure. :)) So the only thing left is why Mod4 + m and Mod4 + f are not working. Like I said, other clientkeys are fine. Any ideas? (I tried with the default rc.lua.) Thanks for your help! Andreas -- To unsubscribe, send mail to [email protected].
