Hey, On 30 April 2012 14:41, Ivan Kanakarakis <[email protected]> wrote: > it seems tabbed is requesting input focus, see line 395 on tabbed.c [0]
There was a private thread about this because the guy who reported it didn't want to subscribe to the mailing list or something. To summarise, On 16 November 2011 21:06, Thomas Adam <[email protected]> wrote: > The latest change in hg for tabbed has reintroduced calls to > XSetInputFocus() -- as per my change in tabbed (138:5eff0bc41822), > XSetInputFocus() should not be used; there is no need for tabbed to > take focus for itself, and doing so by-passes the window manager. On 16 November 2011 21:16, Connor Lane Smith <[email protected]> wrote: > Can you reply to the thread on the mailing list [1]? Apparently > removing XSetInputFocus introduced a bug. > > [1]: http://lists.suckless.org/dev/1109/9350.html On 17 November 2011 15:32, Thomas Adam <[email protected]> wrote: > I can't, since I'm not subscribed to the list. On 5 December 2011 21:19, Roman Z. <[email protected]> wrote: > Before my XSetInputFocus patch was applied, you had to place the mouse > pointer inside the tabbed window, otherwise all keys that you press are > ignored by the program that's embedded in tabbed. > > I tested and confirmed this with the window managers dwm and awesomewm > and with the embedded programs vimprobable2 and urxvt. On 10 December 2011 21:18, Thomas Adam <[email protected]> wrote: > Then the solution to that problem is to listen for EnterNotify events > instead and set focus to c->win as appropriate. On 11 December 2011 13:47, Roman Z. <[email protected]> wrote: > The aim is to be able to type in keys even when the mouse is not inside > the window. I don't see how EnterNotify events, which occur when the > mouse enters the window, have anything to do with it. That was the end of the discussion. I have to say, if it's a choice between using XSetInputFocus or only receiving input when the mouse is over the XEmbed window, I'm going with XSetInputFocus. Thanks, cls
