Roger Oberholtzer <
roger.ob...@gmail.com> wrote:
> On Tuesday, April 4, 2017 at 11:43:05 AM UTC+2, Arjen Markus wrote:
>
>> Could you post an example to illustrate what you are doing? ISTR
>> some trick involved with this, but I remember no details atm.
>
> I think this does the trick. After starting the program, select
> either entry in .a (text "vara1", or "vara2"). When you press 'x',
> the text "varb2" should be highlighted. But the focus stays in the
> entry. Anything you type will not be in varb2.
>
> Now, select 'varb1'. Press x. The text in other entry in that window
> is highlighted and the focus is set there. Anything you type is sent
> to the varb2 window.
>
> Same callback. Same requested actions. But focus does not move to a
> different toplevel
It appears to work perfectly on Linux with Fvwm2 set to sloppy focus
mode.
Note that Harold's reply is on point. Focus, and what window has focus
(both keyboard and mouse) is the responsibility of the window manager
on X windows. Applications merely ask that focus be moved, but the
window manager can (if it wants) completely override that request and
do something different. So you are likely seeing an aspect where your
window manager is overriding what it is your Tk program wishes to do.
Case in point, an old version of openoffice (I forget which version
now) was *very* bad about both stealing focus *and* popping itself to
the top whenever my mouse entered its windows. So, I did a little
reconfiguring of my fvwm2 config to instruct fvwm2 to totally ignore
both "raise" as well as "focus" requests from it. Problem solved.