Moving focus between toplevels

[Roger Oberholtzer]

I have an application with a number of toplevel windows. When the user presses a specific key, I want the focus to move to a specific window. So, obviously, I thought I would use the focus command.

Unfortunately, something seems not to be working. Say we have toplevel .a and toplevel .b, and the focus is currently in something in .b. When the key is pressed, I want something in .a to have focus.

I have bound the keypress, and I know it is working. In addition to moving focus, the text in the field that should take focus is highlighted. The highlighting always happens as expected. The problem is that if the focus is not already somewhere in .a, the focus does not happen.

This is on Linux/KDE, with 8.6.1. I know that is a bit old, but I cannot change the Tcl version. It also happens in an even older system with Tcl 8.5.12

I have tried adding -force to the focus command, but it makes no difference. Have I perhaps not considered something?

--
Roger Oberholtzer

[Arjen Markus]

Could you post an example to illustrate what you are doing? ISTR some trick involved with this, but I remember no details atm.

Regards,

Arjen

[Harald Oehlmann]

AFAIR, this might be an issue with the Windows Manage, which might deny
it. There might be settings to allow it.

Harald

[Harald Oehlmann]

Am 04.04.2017 um 11:43 schrieb Arjen Markus:

(repost due to many typing errors)

AFAIK, this might be an issue with the Windows Manager, which might deny

[Alexandru]

Just a hunch: Use "after idle" in conjunction with the focus command?

[Roger Oberholtzer]

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

### Start of sample
# Make two top levels. Put an entry in each

toplevel .a
set vara1 vara1
grid [entry .a.e1 -textvariable vara1 -takefocus 1] -sticky {e w n s} -row 0 -column 1
set vara2 vara2
grid [entry .a.e2 -textvariable vara2 -takefocus 1] -sticky {e w n s} -row 1 -column 1

toplevel .b
set varb1 varb1
grid [entry .b.e1 -textvariable varb1 -takefocus 1] -sticky {e w n s} -row 0 -column 1
set varb2 varb2
grid [entry .b.e2 -textvariable varb2 -takefocus 1] -sticky {e w n s} -row 1 -column 1

# Set the intitial focus to vara1 (.a1.e1)

focus .a.e1

# bind the x key to be to move focus to .b.e2

bind all x {
.b.e2 selection range 0 end
focus .b.e2
}

# End of sample

--
Roger Oberholtzer

[Alexandru]

Am Dienstag, 4. April 2017 14:31:39 UTC+2 schrieb Roger Oberholtzer:
> 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.

But it works in my case (Win 7, Tcl 8.6.6)! I can't confirm the described behavior.

[Roger Oberholtzer]

On Tuesday, April 4, 2017 at 3:36:40 PM UTC+2, Alexandru wrote:

> But it works in my case (Win 7, Tcl 8.6.6)! I can't confirm the described behavior.

I am suspecting something related to KDE on Linux. It is the same for a couple versions of KDE. So I do not think it is a bug. More likely a window manager setting.

I added a trace for when the window gets focus. When I click on a window, I get the expected focus message. However, when I am in .a, and press x, it tells me that .a is getting focus. Not .b, which is the one that should get focus!

# Start of test

# Make two top levels. Put an entry in each

toplevel .a

wm protocol .a WM_TAKE_FOCUS {puts ".a gets focus"}

set vara1 vara1
grid [entry .a.e1 -textvariable vara1 -takefocus 1] -sticky {e w n s} -row 0 -column 1
set vara2 vara2
grid [entry .a.e2 -textvariable vara2 -takefocus 1] -sticky {e w n s} -row 1 -column 1

toplevel .b

wm protocol .b WM_TAKE_FOCUS {puts ".b gets focus"}

set varb1 varb1
grid [entry .b.e1 -textvariable varb1 -takefocus 1] -sticky {e w n s} -row 0 -column 1
set varb2 varb2
grid [entry .b.e2 -textvariable varb2 -takefocus 1] -sticky {e w n s} -row 1 -column 1

# Set the intitial focus to vara1 (.a1.e1)

focus .a.e1

# bind the x key to be to move focus to .b.e2

bind all x {
.b.e2 selection range 0 end
focus .b.e2
}

# End of test

--
Roger Oberholtzer

[Rich]

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.

[Donald Arseneau]

Roger Oberholtzer <roger.ob...@gmail.com> writes:

> 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

For KDE plasma...
Open the settings/preferences window.
Click Window behavior
Select the Focus tab
Set Focus stealing prevention level to None.

Even the default "Low" level of protection prevents this focus change.



--
Donald Arseneau as...@triumf.ca

[Roger Oberholtzer]

On Wednesday, April 5, 2017 at 1:30:39 AM UTC+2, Donald Arseneau wrote:

> For KDE plasma...
> Open the settings/preferences window.
> Click Window behavior
> Select the Focus tab
> Set Focus stealing prevention level to None.
>
> Even the default "Low" level of protection prevents this focus change.

That was it! That setting exists on the earlier versions of KDE as well. It was set to Low. Of course, now that it has been changed, who knows what other applications may do. But that's a different issue.

Thanks!

--
Roger Oberholtzer