On 24.12.2011 02:02, Matthew Hague wrote: > > On Fri, Dec 23, 2011 at 10:16:40 +0100, Uli Schlachter wrote: >> On 23.12.2011 21:08, Matthew Hague wrote: >>> I tried to track this a little more and added a "focus" signal to see what >>> Awesome thinks is gaining focus. Even in the cases when focus in goes >>> missing, a "focus" signal gets generated. However, this is a bit weird, >>> because putting the mouse over Evince and executing client.focus = >>> client.focus doesn't generate a "focus" signal, but does generate the focus >>> in >>> event... >> >> What exactly did you patch for that? > > The focus in event was received by the evince window (shell/ev-window.c) -- i > added a few printfs to the evince source to see what was going on... > >> You could also install xtrace (no the glibc-thingie, but the x11 trace >> thingie) >> and let us know what exactly awesome is doing. > > I've attached the full log of a failing run [..]
Hm. The working and the non-working case look the same (even with the surrounding requests and events). The only difference that I can spot is mode=WhileGrabbed vs mode=Normal, but that shouldn't make a difference. Anyone knows a GTK hacker who got some spare time and can figure this out? I'd be curious about what exactly gtk is expecting here and why it is ignoring the events (aka "What does it thing does have the input focus? Why does it think so?) Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to [email protected].
